AFRL-IF-WP-TR-2001-1530 


/; 


INCREMENTAL  UPGRADE  OF  LEGACY 
SYSTEMS  (ILLS) 

Don  Winter 
David  Corman 
Pat  Goertzen 
Tom  Herm 
John  Shackleton 


The  Boeing  Company 

P.O.  Box  516 

St.  Louis,  MO  63166-0516 


APRIL  2001 

Final  Report  for  30  September  1996  -  28  February  2001 


Approved  for  public  release;  distribution  is  unlimited. 


INFORMATION  DIRECTORATE 

AIR  FORCE  RESEARCH  LABORATORY 

AIR  FORCE  MATERIEL  COMMAND 

WRIGHT-PATTERSON  AIR  FORCE  BASE,  OH  45433-7334 


NOTICE 


USING  GOVERNMENT  DRAWINGS,  SPECIFICATIONS,  OR  OTHER  DATA 
INCLUDED  IN  THIS  DOCUMENT  FOR  ANY  PURPOSE  OTHER  THAN 
GOVERNMENT  PROCUREMENT  DOES  NOT  IN  ANY  WAY  OBLIGATE  THE  US 
GOVERNMENT.  THE  FACT  THAT  THE  GOVERNMENT  FORMULATED  OR 
SUPPLIED  THE  DRAWINGS,  SPECIFICATIONS,  OR  OTHER  DATA  DOES  NOT 
LICENSE  THE  HOLDER  OR  ANY  OTHER  PERSON  OR  CORPORATION;  OR 
CONVEY  ANY  RIGHTS  OR  PERMISSION  TO  MANUFACTURE,  USE,  OR  SELL  ANY 
PATENTED  INVENTION  THAT  MAY  RELATE  TO  THEM. 

THIS  REPORT  IS  RELEASABLE  TO  THE  NATIONAL  TECHNIAL  INFORMATION 
SERVICE  (NTIS).  AT  NTIS,  IT  WILL  BE  AVAILABLE  TO  THE  GENERAL  PUBLIC, 
INCLUDING  FOREIGN  NATIONS. 

THIS  TECHNICAL  REPORT  HAS  BEEN  REVIEWED  AND  IS  APPROVED  FOR 
PUBLICATION. 


MICHAEL  T.  MILLS 


JAMES  S.  WILLIAMSON,  Chief 
Embedded  Info  Sys  Engineering 
Information  Technology  Division 
Information  Directorate 


Project  Engineer 


for  EUGENE  BLACKBURN,  Chief 
Information  Technology  Division 
Information  Directorate 


This  report  is  published  in  the  interest  of  scientific  and  technical  information  exchange 
and  does  not  constitute  approval  or  disapproval  of  its  ideas  or  findings. 


Do  not  return  copies  of  this  report  unless  contractual  obligations  or  notice  on  a  specific 
document  requires  its  return. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  0704-0188 


The  public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  searching  existing  data 
sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of 
information,  including  suggestions  for  reducing  this  burden,  to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports  (0704-0188),  1215  Jefferson 
Davis  Highway,  Suite  1 204,  Arlington,  VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any  penalty  for  failing  to  comply  with  a 
collection  of  information  if  it  does  not  display  a  currently  valid  0MB  control  number.  PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 

1.  REPORT  DATE  (DD-MM-YY)  2.  REPORT  TYPE  |  3.  DATES  COVERED  (From  -  To) 

April  2001 _ Final _ 

4.  TITLE  AND  SUBTITLE 

INCREMENTAL  UPGRADE  OE  LEGACY  SYSTEMS 


6.  AUTHOR(S) 

Don  Winter 
David  Corman 
Pat  Goertzen 
Tom  Herm 
John  Shackleton 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

The  Boeing  Company 
P.O.  Box  516 
St.  Louis,  MO  63166-0516 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Information  Directorate 
Air  Eorce  Research  Laboratory 
Air  Eorce  Materiel  Command 
Wright -Patterson  APB,  OH  45433-7334 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 

13.  SUPPLEMENTARY  NOTES 

Report  contains  color. _ 

14.  ABSTRACT 

This  program  developed,  demonstrated,  and  is  transitioning  technology  that  will  enable  cost-effective,  incremental 
improvements  to  fielded  embedded  systems.  The  lULS  wrapper  technology  was  flight  tested  on  an  P-15  with  no 
anomalies.  lULS  software  tools  automatically  generated  99  percent  of  the  wrapper  software.  This  technology  provides  a 
low  risk,  affordable  approach  to  system  upgrades  in  response  to  computer-diminished  manufacturing  resources.  It 
supports  faultless  and  simultaneous  execution  of  new  and  legacy  software  and  can  be  used  to  accelerate  the  insertion  of 
new  technology  into  Air  Eorce  weapon  systems  and  information  systems. 

The  lULS  program  consisted  of  two  tasks.  Task  1  was  to  define  incremental  software  upgrade  processes  and  supporting 
avionics  architectures,  identify  and  evaluate  candidate  solutions,  and  identify  the  preferred  approaches  for 
demonstration.  Task  2  was  to  develop  reusable  legacy  wrappers,  adapt  an  off-the-shelf  CASE  toolset  to  lULS  specific 
needs,  mature  the  incremental  software  upgrade  process  by  using  the  CASE  toolset  to  configure  a  wrapper  for  the  E-15 
OEP,  demonstrate  the  wrapped  OEP  on  a  COTS  multiprocessor,  and  transition  this  technology  to  customer-selected 
weapon  systems  avionics  upgrade  programs.  lULS  emulation  technology  was  successfully  demonstrated  on  C-17 
hardware  in  the  C-17  integration  laboratory. 


15.  SUBJECT  TERMS 

software  middleware,  software  wrappers,  CORBA,  lULS 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION 

18.  NUMBER 

19a.  NAME  OF  RESPONSIBLE  PERSON  (Monitor) 

a.  REPORT 

b.  ABSTRACT 

c.  THIS  PAGE 

OF  ABSTRACT: 

OF  PAGES 

Michael  T.  Mills 

Unclassified 

Unclassified 

Unclassified 

SAR 

122 

19b.  TELEPHONE  NUMBER  (Include  Area  Code) 

(937)  255-6548  x3583 

Standard  Form  298  (Rev.  8-98) 

HES&S  31-15093-1  Prescribed  by  ANSI  Std.  Z39-18 

i 


_ I  09/30/1996  -  02/28/2001 _ 

5a.  CONTRACT  NUMBER 

(lULS)  P33615-96-C-1969 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

_ 63253P _ 

5d.  PROJECT  NUMBER 

3833 _ 

5e.  TASK  NUMBER 

04 _ 

5f.  WORK  UNIT  NUMBER 

_ 02 _ 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

BOEING-STL-00P0074 

10.  SPONSORING/MONITORING  AGENCY 
ACRONYM(S) 

AERL/IETA _ 

11.  SPONSORING/MONITORING  AGENCY 
REPORT  NUMBER(S) 

APRL-IP-WP-TR-2001-1530 


TABLE  OF  CONTENTS 

Section  Page 

List  of  Figures . vi 

List  of  Tabies . vii 

1  Scope . 1 

1.1  Identification . 1 

1.2  Program  Overview . 1 

1.2.1  Program  Plan . 1 

1.3  Document  Overview . 2 

2  Referenced  Documents . 3 

3  Background . 4 

3.1  Software  Wrappers . 4 

3.2  Wrapping  Process . 5 

4  F-15  lULS  Demonstration . 7 

4.1  Customer  Upgrade  Requirement . 7 

4.2  Domain  Analysis  of  Legacy  and  Upgrade . 8 

4.2. 1  Characterize  Legacy  OFP . 8 

4.2.2  Characterize  Host . 13 

4.2.3  Host  OFP  Model . 14 

4.3  Designing  the  Wrapper . 18 

4.3.1  Wrapper  Initialization . 21 

4.3.2  Wrapper  Control . 21 

4.3.3  Process  And  Data  Synchronization . 23 

4.3.4  Shared  Data  Access . 23 

4.3.5  External  Data  Access . 26 

4.4  Development  Environment . 26 

4.5  Wrapper  Implementation . 27 

4.5.1  Build/Modify  Wrapper  Model . 27 

4.5.2  Build/Modify  Wrapper  Components . 35 

4.5.3  Generate  Wrapper  Code . 35 

4.5.4  Unk  With  OFP . 37 

4.5.5  Evaluate  Wrapped  System . 37 

4.6  Test  Wrapped  System . 38 

4.7  F-15  Demonstration  Summary . 38 

5  C-17  lULS  Demonstration . 40 

5.1  Emulator  Framework . 40 

5.1.1  Emulator  Trade  Study . 40 

5.1.2  Emulator  Strawman  Architecture . 42 

5.1.3  Emulation  Environment . 42 

5.1.4  Emulation  T ool  Selection . 43 

5.2  C-17  Avionics . 44 


TABLE  OF  CONTENTS  (continued) 

Section  Page 

5.3  Customer  Upgrade  Requirement . 45 

5.3.1  C-17APM . 45 

5.3.2  C- 17  ecu . 48 

5.3.3  C-17C1P . 48 

5.4  ecu  Laboratory  Demonstration . 50 

5.4.1  Phase  1 . 51 

5.4.2  Phase  2 . 52 

5.5  C-17  Technology  Demonstration  1  (TD-1 ) . 56 

5.6  C-17  Technology  Demonstration  2  (TD-2) . 59 

5.7  C-17  Communications  Open  System  Architecture  ( COSA) . 61 

5.8  C-17  Summary . 64 

6  Perimeter  Attack  Radar  Characterization  System  Anaiysis . 66 

6.1  lULS  TooTset  Applicability  to  PARCS  Hardware  Obsolescence . 67 

6.1.1  SMP  Issues . 67 

6.1.2  Instruction  Set  Issues . 68 

6.1.3  Basic  Operating  System  (BOS)  Issues . 68 

6.1.4  Tactical  Operating  System  (TOS)  Issues . 68 

6.1.5  Conclusions  Regarding  lULS  Emulation  of  PARCS . 68 

6.2  PARCS  System  Assessment . 68 

6.2.1  PARCS  System  Robustness . 69 

6.2.2  BMEWS/PAVE  PAWS  and  COBRA  DANE  Analyses . 70 

6.2.3  Radar  Architecture  Migration  Program . 7 1 

6.2.4  PARCS  and  National  Missile  Defense . 75 

6.3  PARCS  and  lEIST. . 76 

6.4  PARCS  Summary . 76 

7  lULS  CV-22  Transition . 77 

7. 1  Foundation  Programs . 80 

7.2  lULS  CV-22  Transition  Benefits . 81 

8  Other  Wrapper  Appiications  and  Upgrade  Technoiogy . 83 

8.1  Other  lULS  Applications . 83 

8.1.1  Open  Systems  Architecture  Wrappers . 83 

8.1.2  Wrappers  Eor  Scientific  Computing . 83 

8.1.3  Wrappers  Eor  Business  and  Information  System  Applications . 83 

8.2  Wrappers  and  Software  Reuse . 84 

8.3  Other  Software  Upgrade  Approaches . 84 

8.4  Upgrade  Tools  and  Modeling . 85 

9  lULS  Lessons  Learned  and  Conclusion . 87 

9.1  lULS  Process . 87 

9.2  Upgrade  Programmatics . 87 

9.3  Summary . 88 


IV 


TABLE  OF  CONTENTS  (concluded) 


Section  Page 

10  References . 89 

10.1  Bibliography . 89 

Acronyms  and  Abbreviations . 90 

Giossary . 93 

Appendix  A.  Overbad  Warning  System  /  Common  OFP  Mapping  Tabie . 94 

Appendix  B.  Overioad  Warning  System  Parameter  Stubbing  Tabie . 97 

Appendix  C.  Sampie  WrapidH  C++  Listing . 105 

Appendix  D.  Sampie  WrapidH  Ada  Listing . 108 


LIST  OF  FIGURES 

Figure  Page 


Figure  1 .  Wrapper  Cases . 4 

Figure  2.  Nominai  Legacy  OFF  Wrapper  Process . 6 

Figures.  VCC  and  MPDP  Context . 8 

Figure  4.  VCC  Processor  Configuration . 8 

Figure  5.  VCC  DPM  Software  Structure . 10 

Figure  6.  VCC  DPM  Controi  Fiow . 1 1 

Figure  7.  VCC  lOM  Software  Structure . 1 1 

Figure  8.  VCC  lOM  Controi  Fiow . 1 1 

Figure  9.  ADCP  Processor  Configuration . 14 

Figure  10.  Comparison  of  VCC  and  ADCP  OFP  Execution . 14 

Figure  11.  F-1 5  VCC  Rehost  Candidate  #1 . 16 

Figure  12.  F-1 5  VCC  Rehost  Candidate  #2 . 16 

Figure  13.  F-15  OWS  Demonstration  Process . 18 

Figure  14.  Generic  Rehost  Wrapper  Architecture . 19 

Figure  15.  OWS  Structure . 20 

Figure  16.  Typicai  Data  Transform  for  Preiiminary  Wrapper  Design . 20 

Figure  17.  OWS  Wrapper  Architecture . 24 

Figure  18.  WrapidFI  Tooiset . 27 

Figure  19.  Upgraded  Software  Architecture . 27 

Figure  20.  Top  Levei  Wrapper  Modei . 28 

Figure  21 .  Perform  OWS  20FIZ  Wrapper  (Part  1 ) . 29 

Figure  22.  Perform  OWS  20FIZ  Wrapper  (Part  2) . 31 

Figure  23.  OWS  Transfer  to  Ada . 32 

Figure  24.  OWS  20  FIz  Copy  Outputs . 33 

Figure  25.  Dispiay  NZ . 34 

Figure  26.  Component  Properties . 35 

Figure  27.  Component  Code . 36 

Figure  28.  Generate  Wrapper  Code . 36 

Figure  29.  Emuiator  Architecture . 40 

Figure  30.  Emuiator  Strawman  Architecture . 42 

Figure  31 .  Overview  of  TRW’s  RePLACE  Emuiator . 43 

Figure  32.  APM  Context . 45 

Figure  33.  APM  Flardware  Configuration . 46 

Figure  34.  Pianned  C-17  APM  Demonstration . 47 

Figure  35.  Optionai  C-17  APM  Demonstration . 47 

Figure  36.  CCU  Laboratory  Demonstration  Concept . 48 

Figure  37.  CIP  Context . 49 

Figure  38.  CIP  Hardware  Configuration . 49 

Figure  39.  CCU  Demo  Gates . 50 

Figure  40.  Demonstration  Definition . 51 

Figure  41 .  Demonstration  Scheduie . 52 

Figure  42.  C-17  IRMS  Eiements  Demonstrated  in  Phase  2  (Logicai  View) . 53 

Figure  43.  Phase  2  Demonstration  Configuration  (Physicai  View) . 54 

Figure  44.  CCU  OFP  Architecture  Components . 54 

Figure  45.  Overview  of  Emuiated  I/O . 55 

Figure  46.  Post  Demonstration  Risk  Assessment . 56 

Figure  47.  CCU  Demonstration  Pian  (Logicai  View) . 57 

Figure  48.  CCU  Demo  Gates . 58 

Figure  49.  TD-1  Demonstration  Configuration . 59 

Figure  50.  CRB  CIP  Integration  Pian . 60 

Figure  51.  COSA  Program  History . 62 

Figure  52.  Key  COSA  Program  Features . 62 

Figure  53.  Key  COSA  /  lULS  Deveiopment  Processes . 63 

Figure  54.  Key  COSA  /  lULS  Deveiopment  Processes  (Cont.) . 64 


VI 


LIST  OF  FIGURES  (concluded) 


Figure  Page 


Figure  55.  lULS  Emulation  of  PARCS  SMP  Architecture . 71 

Figure  56.  lULS  Emulator  and  RAM  TRM . 73 

Figure  57.  CV-22  Program  Roadmap . 77 

Figure  58.  CAAP  Program  Elements . 78 

Figure  59.  CV-22  Processor  Architecture  and  CRB  Migration . 78 

Figure  60.  Legacy  and  Demonstration  System  Architecture . 79 

Figure  61.  F-15E  Options  for  Rehost . 80 

Figure  62.  Tech  Demo  Components  Selected  for  CAAP  Relevancy  (Preliminary) . 81 

Figure  63.  CV-22  Demonstration  Software  Architecture . 81 

Figure  64.  CV-22  Demonstration  Outputs . 82 


vii 


LIST  OF  TABLES 

Table  Page 


Table  1.  F-15E  Upgrade  Candidates . 7 

Table  2.  VCC  Features  and  Modules . 9 

Tables.  VCC  Segments . 10 

Table  4.  VCC  Feature  Upgrade  Impact . 12 

Table  5.  Example  of  DPMI  Processing  Tasks/Times/Instructions  Model . 13 

Table  6.  OWS/COFP  Mapping . 24 

Table  7.  OWS/COFP  Stubs . 25 

Table  8.  Software  Component  Size . 37 

Table  9.  Software  Throughput  Usage . 37 

Table  10.  Emulator  Candidates . 41 

Table  11.  Emulator  Trade  Study . 42 

Table  12.  C-17  Subsystems . 44 

Table  13.  PARCS  System  Architecture  Analysis . 74 

Table  14.  PARCS  Software  Architecture  Analysis . 75 


viii 


1  Scope 


1.1  Identification 

This  technical  report  was  developed  for  the  Incremental  Upgrade  of  Legacy  Systems  (lULS)  research  and 
development  (R&D)  program  by  The  Boeing  Company  (formerly  McDonnell  Douglas  Aerospace)  under 
Contract  No.  F33615-96-C-1969  for  Air  Force  Research  Laboratory,  Information  Directorate  AFRL/IFTA. 
General  Dynamics  Information  Systems  (GDIS)  and  Honeywell  Technology  Center  (HTC)  participated. 

1 .2  Program  Overview 

The  lULS  program  is  an  R&D  effort  whose  main  objective  is  to  develop,  demonstrate,  and  transition 
technology  that  enables  cost-effective,  incremental  improvements  to  fielded  weapon  system  avionics.  The 
program  was  structured  as  two  tasks  as  described  in  the  lULS  Technical  Proposal.  The  objectives  of 
Task  1  were  to: 

•  Define  incremental  software  upgrade  processes 

•  Define  the  supporting  avionics  architectures 

•  Identify  and  evaluate  candidate  solutions 

•  Identify  the  preferred  approaches  for  demonstration  and  transition  in  Task  2. 

The  objectives  of  Task  2  were  to: 

•  Develop  reusable  legacy  wrappers 

•  Adapt  an  off-the-shelf  Computer  Aided  Software  Environment  (CASE)  toolset  to  lULS  specific  needs 

•  Mature  the  incremental  software  upgrade  process  by  using  the  CASE  toolset  to  configure  a  wrapper 
for  the  F-15  OFP 

•  Demonstrate  the  “wrapped”  Operational  Flight  Program  (OFP)  on  a  Commercial  Off  The  Shelf  (COTS) 
multiprocessor 

•  Transition  this  technology  to  customer-selected  weapon  system  avionics  upgrade  programs. 

1.2.1  Program  Plan 

During  Task  1,  a  Domain  Analysis  was  performed  to  describe  and  analyze  current  avionics  software 
architectures  and  upgrade  methods.  The  analysis  task  employed  SEI’s  Feature-Oriented  Domain  Analysis 
methodology  (see  FODA  reference)  and  included  several  phases: 

•  Context  Analysis 

•  Establish  the  scope  and  environment  of  upgrade  domains  in  the  F-15  and  C-17 

•  Identify  application  software  classes  and  host  processors 

•  Describe  each  domain’s  structure  and  context 

•  Domain  Modeling 

•  Generate  models  of  the  candidate  domains  including  current  and  future  configurations 

•  Wrapper  Modeling  and  Simulation 

•  Generate  simulations  of  the  candidate  domain  models  and  host  hardware  using  PML-VHDL 
models  as  appropriate 

•  Map  the  candidate  domain  models  to  the  proposed  wrapper  software  architecture  to  identify 
potential  solutions  to  the  application’s  upgrade  “problems” 

•  Evaluate  the  performance  of  the  candidate  solutions 

•  Identify  Best  Solution  For  Demonstration  and  Transition 

•  Identify  and  specify  a  wrapper  framework  which  implements  the  solutions 

•  Define  the  wrapper  process  and  tool  capabilities  required 

Task  2  built  upon  the  foundation  established  during  Task  1.  Task  2  followed  a  more  product-oriented 
methodology  in  which  the  wrapper  development  process  developed  in  Task  1  was  applied  to  several 
domains.  During  Task  2,  the  preferred  candidates  identified  during  Task  1  for  Demonstration  and 
Transition,  the  F-15  and  C-17,  were  matured,  and  more  detailed  solutions  were  developed.  In  the  case  of 
the  F-15,  the  demonstration  was  pursued  through  completion  under  lULS  Task  2.  For  the  C-17,  the 
demonstration  was  defined  under  lULS  Task  2  and  executed  under  a  separate  contract.  Under  lULS  Task 
2  additional  transition  candidates,  the  Perimeter  Attack  Radar  Characterization  System  (PARCS)  and  the 
CV-22,  were  also  analyzed  according  to  the  Task  1  process.  For  PARCS  application  of  the  process 
disclosed  that  it  was  not  a  valid  lULS  candidate,  while  application  of  the  process  to  the  CV-22  resulted  in 
proceeding  with  upgrade  development  under  a  separate  contract  vehicle. 
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The  F-15  efforts  included: 

•  Complete  trade  to  finalize  decision  on  the  content  of  the  F-15  lULS  demonstration 

•  Design  the  wrapper 

•  Map  inputs  and  outputs 

•  Map  control  flow 

•  Build/modify  wrapper  model 

•  Build  /modify  wrapper  components 

•  Generate  wrapper  code 

•  Link  with  OFF 

•  Flight  test  wrapped  system 

•  Evaluate  wrapped  system 

The  C-17  efforts  included: 

•  Complete  trade  to  finalize  decision  on  the  content  of  the  C-17  lULS  demonstration 

•  Transition  demonstration  to  alternative  contractual  vehicle  leading  to  an  in-context  demonstration  to  be 
conducted  in  C-17  Avionics  Integration  Area  and  potential  transition  to  emerging  Communications  Open 
System  Architecture  (COSA)  EMD  opportunity 

•  Complete  requisite  training  and  staff  familiarization  with  lULS  toolset 

The  PARCS  efforts  included: 

•  Execute  domain  analysis  to  determine  the  feasibility/cost  effectiveness  of  an  incremental  upgrade 
The  CV-22  efforts  included: 

•  Complete  trade  to  finalize  decision  on  the  content  of  the  CV-22  lULS  demonstration 

•  Transition  demonstration  to  alternative  contractual  vehicle 

•  Complete  requisite  training  and  staff  familiarization  with  lULS  tool-set 

1 .3  Document  Overview 

This  report  provides  details  of  all  Task  2  activities,  organized  along  product  lines  F-15,  C-17,  PARCS  and 
CV-22.  Task  1  results  specific  to  these  Task  2  activities  are  included  in  the  appropriate  product  line 
discussions.  For  the  F-15  demonstration,  a  complete  description  of  the  lULS  Task  1  and  Task  2  efforts, 
including  lessons  learned,  is  provided.  For  the  C-17  details  of  the  efforts  executed  under  lULS  Task  1  and 
Task  2,  which  led  up  to  the  separately  funded  C-17  Technology  Demonstration,  are  provided.  Aspects  of 
the  separately  contracted  C-17  Technology  Demonstration,  which  are  significant  regarding  the  use  of  lULS 
tools,  are  also  presented.  Similarly,  for  the  CV-22,  lULS  Task  2  activities  which  led  up  to  the  CV-22 
Technology  Demonstration  along  with  lessons  learned  during  the  demonstration  are  provided  herein.  The 
remaining  details  of  the  G17  and  CV-22  demonstrations  will  be  provided  in  separate  reports,  prepared 
under  the  contracts  governing  their  execution.  For  PARCS,  the  lULS  Task  2  efforts,  which  ultimately 
rejected  PARCS  as  an  incremental  upgrade  candidate,  are  summarized.  Details  of  the  lULS  Task  2 
PARCS  analysis  have  already  been  provided  under  a  separate  lULS  submission.  This  report  concludes 
with  a  summary  of  important  lessons  learned  during  execution  of  Task  2  as  well  as  the  other  separately 
contracted  lULS  demonstrations. 
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3  Background 

Avionics  upgrades  are  frequent  and  occur  for  many  reasons,  inciuding  warfighting  enhancements, 
countering  changing  threats,  hardware  obsoiescence,  and  computer  resource  under-capacity.  In  the  iong 
term,  the  probiem  of  cost-effectiveiy  upgrading  iegacy  systems  can  be  mitigated  through  re-engineering 
with  the  iatest-generation  hardware  and  architecturai  concepts,  inciuding  object-oriented  software  design, 
which  inherentiy  contain  and  isoiate  change.  On  the  other  hand,  iegacy  avionics  software  represents  a 
iarge  investment  in  deveiopment  toois,  executabie  code,  and  ground  and  fiight  quaiification.  Shouid  the 
upgrade  require  compiete  re-engineering  of  this  iegacy  software,  much  of  this  investment  is  iost,  and  many 
aircraft  programs  simpiy  cannot  afford  the  up-front  costs  associated  with  re-engineering  and  compiete 
requaiification. 

A  typicai  production  avionics  upgrade  cycie  for  miiitary  aircraft  frequentiy  invoives  embedded  software 
changes.  New  versions  of  mission  processor  software,  which  is  the  most  voiatiie  ciass  of  avionics 
software,  are  typicaiiy  reieased  annuaiiy  and  take  two  years  to  fieid  from  initiai  definition.  One  such 
upgrade  may  put  resource  usage  over  the  contractuaiiy  imposed  spare  iimit  or  the  actuai  hardware 
capacity.  Hardware  obsoiescence  occurs  coiiectiveiy  over  a  ionger  term  as  vendors  change  their  business 
(miiitary/commerciai  mix)  and  technoiogy.  Software  toois  and  technoiogy  aiso  evoive  over  a  ionger  period 
but  may  be  driven  by  short-term  events  such  as  the  introduction  and  imposition  of  Ada.  The  change  cycies 
are  not  synchronized  so  the  optimai  hardware,  software  and  tooi  technoiogy,  and  respective  program 
funding  to  support  an  avionics  upgrade  at  a  given  point  in  time  are  often  not  avaiiabie. 

One  soiution  to  this  diiemma  is  impiementing  re-engineering  incrementaiiy  by  inserting  the  iatest  technoiogy 
in  smaiier,  affordabie  steps,  thereby  reducing  risk  and  deferring  or  reducing  cost.  Software  wrapper 
technoiogies  hoid  particuiar  promise  in  meeting  this  chaiienge. 

3.1  Software  Wrappers 

A  wrapper  is  a  software  adapter  or  sheii,  which  isoiates  a  software  component  from  other  components 
and  its  processing  environment  (its  context).  The  wrapped  component  becomes  a  software  object.  Its 
operational  capability  (functions  and  data)  is  encapsulated,  and  it  can  be  integrated  through  its  standard 
interface  with  other  software  objects  to  form  an  OFP  on  a  single  or  distributed  processor  host.  The 
wrapper  manages  the  timeliness  of  all  shared  and  external  data,  and  provides  any  necessary 
transformations. 

For  upgrades,  the  goal  is  to  develop  the  new  or  re-engineered  applications  using  the  latest  software 
engineering  techniques  (such  as  object  oriented  design)  and  languages  (Ada  and  C-i-i-)  with  minimal 
concessions  to  the  internal  structure  of  the  legacy  system  -  as  if  all  other  applications  were  resident  in  the 
new  environment.  Because  the  new  software  is  written  within  the  paradigms  of  00  design  and  languages, 
the  wrapper  could  eventually  be  removed  once  all  of  the  application  functions  had  migrated  to  the  new 
system.  At  this  time,  the  legacy  system  could  be  removed. 

The  following  figure  illustrates  three  hypothetical  cases  of  implementing  software  changes  using  wrappers. 
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Figure  1 .  Wrapper  Cases 
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Rehost.  In  the  Rehost  Case,  the  legacy  processor  is  obsolete  and/or  its  resources  are  insufficient  to 
support  additional  upgrades.  The  legacy  software  is  re-hosted  to  a  new  processor  by  translating  its 
source  code  and/or  recompiling  it  for  the  new  target.  Re-engineering  the  OFP  on  the  new  processor  could 
not  be  justified  so  wrapper  components  are  added  to  make  it  “look  like”  an  object  in  the  OFP.  New 
software  features  can  be  added  incrementally  to  the  wrapped  component,  or  preferably,  designed  as  new 
objects  in  the  OFP. 

Boeing’s  AV-8B  Common  Navigation  CNAV  demonstration  is  an  example  of  the  Rehost  case.  The  legacy 
assembly  language  OFP  had  previously  been  hand-translated  to  C  and  rehosted  on  a  PowerPC  processor 
in  a  prototype  COTS  Mission  Computer.  The  CNAV  object  (upgraded  navigation  features)  was  interfaced 
to  the  legacy  OFP  with  wrapper-like  components  (gaskets). 

Flybrid.  In  the  Hybrid  Case,  the  legacy  processor  and  its  OFP  are  retained  for  various  reasons  (high  re¬ 
engineering  or  logistics  costs,  etc.),  but  its  resources  are  insufficient  to  support  additional  upgrades.  Also, 
there  is  an  opportunity  to  satisfy  upgrade  requirements  with  reuse  library  components  that  are  developed 
with  better  languages  (such  as  Ada95  or  C-i-i-)  and  tools.  New  features  can  be  added  incrementally  to  the 
upgrade  OFP  as  objects  on  the  new  processor.  The  objects  will  be  interfaced  to  the  legacy  OFP  with 
wrapper  components.  As  components  in  the  legacy  OFP  needed  changes,  they  can  be  re-engineered  and 
moved  to  the  new  processor.  At  some  point  in  the  migration,  the  remaining  legacy  components  are 
rehosted,  the  legacy  processor  is  upgraded  or  discarded,  and  the  wrapper  components  in  the  new  OFP, 
associated  with  the  legacy  OFP  interfaces,  can  be  removed. 

The  F-15  Demonstration  described  earlier  is  an  example  of  the  Hybrid  Case.  The  F/A-18  CNAV 
demonstration  was  also  a  hybrid  configuration.  The  legacy  F/A-18  OFP  written  in  assembly  language  was 
running  on  a  bit-slice  processor  card.  CDInt  designed  a  PowerPC  processor  card  that  fits  in  a  spare  slot 
on  the  legacy  backplane.  Gasket  components  were  designed  in  Ada83  and  C  to  run  CNAV  on  the 
PowerPC  and  interface/synchronize  it  with  the  full-up  Navigation  and  Displays  Modules  running  on  the 
legacy  processor. 

Emulate.  Obsolete  or  underpowered  hardware  is  also  addressed  in  the  Emulate  Case.  The  legacy 
software  is  judged  to  be  very  costly  to  re-engineer  and/or  re-qualify.  The  object  code  is  executed  on  the 
new  processor  by  an  emulation  of  the  legacy  processor’s  instruction  set  architecture  (ISA).  Changes  can 
still  be  made  to  the  legacy  executable  using  the  legacy  compiler  and  Software  Engineering  Environment 
(SEE).  The  emulator  and  other  wrapper  components  make  the  legacy  executable  component  (binary)  look 
like  an  object.  Other  feature  upgrades  could  be  added  as  objects  on  the  new  processor. 

The  emulator  approach  has  advantages  for  software  domains  which  are  not  volatile  or  complex,  such  as 
the  C-17  APM’s  OFP,  and  to  safety-critical  software  which  is  costly  to  retest  and  may  be  developed  as 
large,  tightly  coupled  components  with  autocoders  such  as  FCC  OFPs.  Hardware  and  software  emulators 
have  been  proposed  as  part  of  hardware  upgrades  for  F/A-18  and  AV-8B  AYK-14  Mission  Computers  in 
the  past.  However,  the  OFPs  are  very  volatile,  complex,  and  increasing  costly  to  maintain  with  the  legacy 
SEE,  and  the  emulators  would  consume  a  large  share  of  throughput. 

3.2  Wrapping  Process 

As  with  any  other  software  development  activity,  wrapper  creation  follows  a  process  and  is  automated 
with  tools.  However,  a  wrapper  is  a  specialized  type  of  software,  and  the  process  of  creating  a  wrapper 
imposes  special  requirements  on  the  software  development  activity.  This  section  describes  the  process 
and  automation  that  will  be  used  to  create  wrappers. 

The  creation  of  an  OFP  wrapper  follows  the  process  shown  in  the  Integrated  Computer-Aided 
Manufacturing  Definition  Language  (IDEF)O  diagram  in  the  following  figure.  In  an  IDEFO  diagram, 
consumed  inputs  (e.g.,  data  files)  go  in  the  left  side  of  an  activity  box,  generated  outputs  (e.g.,  completed 
design  objects)  emerge  from  the  right  side,  constraints  (e.g.,  requirements,  schedules)  go  in  the  top,  and 
mechanisms  (e.g.,  tool  support)  go  in  the  bottom.  In  this  diagram,  shaded  boxes  represent  activities  of 
greatest  opportunity  for  automation  in  the  lULS  program.  The  subsections  below  describe  tool 
mechanisms  that  support  the  wrapper  design  process  and  the  data  that  flows  between  them. 
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Figure  2.  Nominal  Legacy  OFF  Wrapper  Process 

This  process  has  been  applied  in  the  approach  to  each  of  the  candidate  domains  addressed  during  lULS 
Task  2.  The  remainder  of  this  report  will  detail  the  results  of  applying  the  lULS  wrapper  development 
process  to  the  F-15,  C-17  and  CV-22  avionics  and  to  the  Perimeter  Attack  Radar  Characterization  System 
(PARCS). 
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4  F-1 5  lULS  Demonstration 

4.1  Customer  Upgrade  Requirement 

The  F-1 5  avionics  system  is  a  compiex,  federated  system  which  is  currentiy  fieided  in  two  configurations, 
the  newer  F-15E  and  the  F-1 5  Muiti-Stage  Improvement  Program  (MSIP).  The  foiiowing  tabie  iists  the  F- 
15E  avionics  subsystems  that  are  subject  to  frequent  updates  and  hence  were  candidates  for  the  avionics 
upgrade  demonstration. 


Subsystem 

Major  Functions 

Processor 

OFP 

Language 

Vendor 

HA/V  /  S/W 

Avionics  Interface  Unit 
(AlU) 

Collects  and  processes  discretes, 
performs  signal  conditioning,  and 
packs/unpacks  data  for  the 
AVMUX. 

f750A 

Assembly 

Language 

Boeing  /  Boeing 

Flight  Control  Computer 
(FCC) 

Triple-redundant  computation  of 
flight  control  laws  to  drive  control 
surface  actuators 

3-1750 

JOVIAL 

Lockheed  Martin 
/  Boeing 

Programmable 

Armament  Control  Set 
(PACS) 

Monitors  stores  status  and  controls 
armament  pre-launch  and  release. 
Provides  weapons-avionics 

interfaces 

Z8002  (Old) 
R3000  (New) 

AL  (Old) 

Ada83/C  (New) 

Dynamic 

Controls 

Corporation  / 

DCC 

VFISIC  Central  Computer 
(VCC) 

Mission  systems  processing  for 
navigation,  weapon  control  and 
delivery,  and  cockpit  displays 

1750 

Ada83 

LM  /  Boeing 

Multi-Purpose  Display 
Processor  (MPDP) 

Receives  information  from  other 
subsystems  to  drive  cockpit 
controls  and  displays 

2901  Bit 

Slice 

AL 

Honeywell  / 
Honeywell- 
Boeing 

Tabie  1.  F-15E  Upgrade  Candidates 

The  AlU  is  fairiy  typicai  of  subsystems  that  coiiect  and  condition  discrete  and  anaiog  signais  and  put  them 
on  a  centrai  avionics  muitipiex  bus  (AVMUX)  for  use  by  other  avionics  processors.  It  interfaces  the  Up- 
Front  Controis  (aiphanumeric  screen  and  keypad)  to  the  VCC  and  Muiti-Purpose  Dispiay  Processor 
(MPDP)  via  the  AVMUX.  The  FCC’s  fiight  controi  software  domain  made  it  an  interesting  candidate. 
However  its  upgrade  requirements  were  satisfied  recentiy  with  faster  1750  processors  and  more  memory. 
Its  safety-critical  software  is  not  volatile,  and  retesting  is  very  expensive,  involving  extensive  man-in-the- 
loop,  hardware-in-the-loop,  and  flight  testing.  The  PACS  has  also  been  upgraded  with  RISC  processors 
and  Ada83  stores  management  domain  software. 

The  software  features  of  the  VCC  and  (MPDP)  are  upgraded  yearly  and  currently  make  full  use  of  their 
computational  resources.  The  VCC  hardware  and  software  system  was  upgraded  in  1990.  Its  OFP  was 
manually  translated  from  assembly  language  to  Ada83  and  hosted  on  MIL-STD-1750  processors.  The 
MPDP  is  primarily  a  display  processor  and  driver  and  has  been  the  subject  of  several  hardware 
upgrade/replacement  studies.  Both  subsystems  must  have  additional  memory,  throughput,  and  I/O  bus 
capacity  to  support  new  requirements  for  warfighting  features,  performance,  and  maintainability.  The  F-1 5 
Project  has  developed  a  new  Advanced  Display  Core  Processor  which  will  replace  both  the  VCC  and 
MPDP.  A  prototype  ADCP  was  available  to  the  lULS  Project,  so  it  was  chosen  as  the  upgrade  Host  for 
the  wrapper  demonstration. 

The  F-1 5  VCC  was  a  good  candidate  for  incremental  upgrade  because  it  is  fairly  typical  of  a  mission 
processor  (Mission  Computer),  and  its  software  domain  is  typical  of  the  mission  processing  domain  for  a 
multi-role  fighter  aircraft  (F-1 6,  F-18,  AV-8B).  It  performs  navigation  and  weapons  delivery  functions  and 
manages  the  cockpit  display  configuration.  Figure  3  represents  the  context  (environment)  in  which  the 
VCC  (bolded  box),  the  MPDP,  and  their  OFPs  operate. 
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Figure  3.  VCC  and  MPDP  Context 


The  VCC  manages  a  federated  system  with  major  interfaces  formed  with  MIL-STD_1553  muitipiex  busses. 
The  F-15E  contains  five  major  busses.  The  muiti-channei  1553  Avionics  Bus  iinks  it  to  the  tacticai  and 
navigationai  sensors  and  vehicie  systems.  The  1553  Dispiay  Bus  iinks  it  to  the  MPDP  that  drives  the 
controis  and  dispiays.  And  the  FI009  Bus  (simiiar  to  MIL-STD-1553)  iinks  it  to  oider  navigationai  sensors 
and  the  stores  management  system  (PACS).  The  VCC  is  the  primary  bus  controiier  (the  MPDP  is  the 
backup),  and  sustains  the  highest  data  voiume  with  the  MPDP. 

4.2  Domain  Analysis  of  Legacy  and  Upgrade 

The  first  step  in  the  upgrade  process  was  to  anaiyze  and  characterize  the  Legacy,  new  Flost  and  upgrade 
system  and  software.  The  Feature  Oriented  Domain  Anaiysis  approach  (FODA,  see  SUM  References) 
was  used  for  this  step,  which  inciudes  three  phases:  Context  anaiysis,  domain  modeiing,  and  architecture 
modeiing.  Since  F-15  upgrades  were  previousiy  anaiyzed  and  the  avionics  system  is  weii  documented,  the 
lULS  FODA  was  done  at  a  high  ievei  as  described  in  the  lULS  Task  1  Final  Report.  For  other  iegacy 
systems  that  are  iess  known/documented,  or  for  more  compiex  upgrades,  a  formai,  detaiied  anaiysis  is 
recommended. 

4.2.1  Characterize  Legacy  OFP 

The  VCC  OFP  is  executed  on  six  processor  cards  as  shown  in  the  foiiowing  figure. 


1553Channel5&8  HOOS  ChanneM  /3  &  2/4  Discrete  I/O 


Figure  4.  VCC  Processor  Configuration 
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The  cards  contain  1750  processors  and  receive  the  OFP  ioad  from  the  non-voiatiie  Buik  Memory  Moduie 
at  power-up.  The  two  Data  Processor  Moduies  (DPMs)  do  the  buik  of  the  mission  processing  which  is 
executed  out  of  SRAM  on  each  card.  DPMS  is  an  in-fiight  spare  whose  state  gets  updated  from  DPMI 
and  DPM2  each  computationai  frame  with  “criticai  ioad  data”  for  back-up  and  restart.  The  Input/Output 
Moduies  primariiy  perform  bus  interface  data  processing  but  aiso  do  some  dispiay  format  data  pre¬ 
processing.  The  Timing  and  Discrete  Moduie  processes  discrete  signai  input/output/interrupts,  contains 
the  VCC’s  ciocks/timers,  and  controis  a  muitipie  reiay  card.  Aii  the  cards  and  spare  siots  communicate  via 
a  duai  PI  Bus  (a  high-speed  paraiiei  backpiane  bus)  and  a  test/maintenance  bus. 

The  VCC  OFP  is  structured  into  10  functionai  software  moduies  that  generaiiy  map  to  the  major  features 
that  the  software  provides  to  the  aircrew  as  shown  in  the  foiiowing  tabie. 


Feature 

ID 

Module 

Air-to-air  weapon  targeting  and  delivery 

A 

Air-to-Air 

Air-to-ground  weapon  targeting  and  delivery 

G 

Air-to-Ground 

Aircrew  controls  and  displays 

D 

Controls  &  Displays 

Flight  data  recording 

FR 

Flight  Recorder 

Guidance 

FD 

Flight  Director 

Navigation 

N 

Navigation 

Self-testing,  built-in  test 

B 

Computer  Self-Test 

In-flight  mission  simulation 

Y 

Simulator  Interface 

Avionics  interface  processing  -  multiplex  busses  and  discretes 

VCC  execution  control 

x 

Executive 

Processing  Support 

UTIL 

Utilities  (arithmetic) 

Program  Execution 

RT 

Run  Time 

Tabie  2.  VCC  Features  and  Moduies 

Each  moduie  aiso  executes  DPM  firmware,  which  performs  buiit-in  functions  (BIFs,  such  as  high-speed 
arithmetic  functions)  and  a  memory  ioader  program  (MLP)  to  downioad  the  moduie’s  executabie  ioad  from 
the  Buik  Memory  Moduie. 

4.2.1 .1  Legacy  OFP  Model 

Domain  modeiing  is  integrai  to  characterizing  the  OFP  and  the  Host.  It  is  used  to  describe  aspects  of  the 
behavior  and  architecture  of  the  software  in  the  chosen  domain,  which  are  usefui  in  identifying  commonaiity 
and  upgrade/wrapper  requirements.  This  section  contains  informationai,  behaviorai,  and  feature  modeis 
for  the  F-15  target,  inciuding  definitions  of  the  domain  components  and  terminoiogy.  Subsequent  host 
processor  and  wrapper  component  modeiing  and  simuiation  were  done  seiectiveiy  to  determine  the 
feasibiiity  and  resource  usage  of  wrapper  architectures. 

The  VCC  OFP  consists  of  five  primary  segments  (consisting  of  processes,  resources,  and  subprocesses) 
which  are  executed  on  one  of  the  five  cards  containing  1750  processors.  The  foiiowing  tabie  shows  how 
the  segments  and  moduie  components  are  distributed  on  the  processors. 

A  process  consists  of  Ada  packages,  one  of  which  is  a  driver  procedure  caiied  by  the  EXEC.  Data  is 
communicated  on  a  moduie  and  across  the  Pi  Bus  backpiane  with  Ada  records  in  Process  Interface 
Messages  (PIMs).  They  contain  the  outputs  of  a  process  that  are  needed  by  other  processes  to  run. 
Criticai  Locai  Data  Messages  (CLDs)  are  packages  containing  data  needed  by  the  spare  processor, 
DPM3,  to  restart  a  process  after  reconfiguration.  Its  state  is  updated  each  frame  with  CLDs  from  the 
other  DPMs.  The  processes  from  a  faiied  DPMI  or  DPM2  are  reiocatabie  to  DPMS. 

Processing  and  I/O  is  controiied  by  the  EXEC.  It  is  rate  driven  with  interrupts  at  20  Hz,  10  Hz,  5  Hz  and  1 
Hz.  As  each  process  compietes,  it  issues  a  compietion  event  message  with  its  output  PIM.  The  EXEC 
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checks  that  all  dependencies  (other  processes,  PIM  delivery,  and  resources)  are  satisfied  before 
executing  the  next  process. 


Module 

DPMI  Segment 

DPM2 

lOM  H009 

lOM  H009 

lOM  A5690 

A 

Segment  B 

Segment  H1 

Segment  H2 

Segment  A1 

A/A 

X 

X 

A/G 

X 

CST 

X 

X 

X 

X 

X 

C/D 

X 

X 

X 

X 

X 

EXEC 

X 

X 

X 

X 

X 

FD 

X 

X 

FR 

X 

NAV 

X 

X 

RT 

X 

X 

X 

X 

X 

SI 

X 

X 

X 

X 

X 

UTIL 

X 

X 

X 

X 

X 

I/O  Packinq/Unpacking 

X 

X 

X 

PI  Bus 

X 

X 

X 

X 

X 

Packing/Unpackinq 

Table  3.  VCC  Segments 

The  following  figure  Is  a  software  structure  chart  for  a  DPM,  which  also  Illustrates  the  subdomains  on  the 
card. 


Applications 

Simulation 

Computer 

Interface 

Self-Test 

Critical  Local 

Built-In 

Utilities 

Data 

Functions 

Executive 

Run-Time 
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Figure  5.  VCC  DPM  Software  Structure 

The  application  code  (such  as  A/A  weapons  targeting)  Is  at  the  highest  level  along  with  the  In-fllght 
simulation  data  Insertion  code  and  the  computer  self-test  code.  The  next  level  consists  of  Built-In 
Functions  (which  are  called  In  the  application  code  and  executed  by  a  separate  chip  set  on  the  card).  Utility 
functions,  and  CLD  data  collection  for  DPM3  updating.  The  next  layer  contains  the  Executive  software, 
which  controls  the  execution  of  processes,  segments  and  card  I/O,  the  Ada  compiler-generated  run-time 
code,  and  PIM  data  accumulation  and  dispersion.  At  the  lowest  level,  next  to  hardware/microcode,  the  PI 
Bus  driver  controls  data  transmission  on  the  backplane.  The  on-card  diagnostics,  which  are  conducted  by 
a  separate  chip  set  and  the  BMM-to-DPM  SRAM  loading  program  are  also  at  the  lowest  level. 

Virtually  all  feature  upgrades  affect  the  application  level  domain  with  some  carry-over  Into  the  supporting 
run-time,  EXEC,  and  PIM/CLD  areas.  Wrappers  or  adapters  for  new  processing  which  are  not  added  to 
current  Ada  packages  will  be  Inserted  Into  at  the  middle  layers. 

VCC  processing  Is  performed  In  “segments”  which  are  EXEC-scheduled  collections  of  processes, 
resources,  and  subprocesses.  The  following  figure  Illustrates  the  sequential  flow  of  control  as  a  segment 
executes  on  the  DPM. 
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Figure  6.  VCC  DPM  Control  Flow 


PPM  Execution 

•  The  PIM  records  are  taken  off  of  the  Pi  Bus  and  are  available  to  needy  processes. 

•  The  Executive  schedules  the  20  FIz  processes,  which  are  ready  to  run. 

•  The  output  PIMs  from  the  completed  20  FIz  processes  are  distributed  internally  and/or  on  the  Pi  Bus. 

•  Sub  20  Hz  PIMs  are  taken  off  of  the  Pi  Bus  for  waiting  lower  rate  processes. 

•  The  10  Hz,  5  Hz  and  1  Hz  processes  which  have  their  prerequisite  data  are  scheduled. 

•  The  sub  20  Hz  PIMs  are  distributed  to  users. 

•  The  processor  enters  a  wait  state  until  the  next  segment  (frame). 

The  following  figure  illustrates  the  structure  of  lOM  software. 
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Figure  7.  VCC  lOM  Software  Structure 

The  domains  are  very  similar  to  the  DPM’s.  Some  control  and  display  processing  is  done  in  the  top 
application  layer.  The  next  layer  contains  the  same  kind  of  software  as  the  DPM’s  second  layer.  The  third 
layer  has  software,  which  packs  and  unpacks  (transfers)  data  between  the  MUX  bus  message  formats 
and  the  PIM  record  formats.  The  lOM  executes  segments  on  its  I/O  driver  processor  (lOP)  and  its 
general  purpose  (GP)  1750  processor  as  shown  in  the  following  figure. 


I/O  Processor 


Figure  8.  VCC  lOM  Control  Flow 

I/O  Processor  Execution 

•  The  20  Hz  inputs  from  MUX  participants  are  solicited  and  received. 

•  Special  20  Hz  MUX  I/O  is  performed,  such  as  time-critical  INS  data  turnaround  to  the  Radar. 
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•  The  sub  20  Hz  inputs  from  the  MUX  are  solicited  and  received. 

•  20  Hz  messages  containing  current-frame  computed  data  packed  by  the  GP  are  sent  out  over  the 
MUX. 

•  Sub  20  Hz  messages  are  sent  out. 

GP  Processor  Execution 

•  At  the  start  of  the  20  Hz  frame,  some  simulation  and  display  processing  is  performed. 

•  As  the  current  20  Hz  MUX  inputs  are  received  by  the  I/O  processor,  they  are  unpacked  into  PIMs  and 
distributed  over  the  Pi  Bus. 

•  Once  the  sub  20  Hz  inputting  is  completed  by  the  lOP,  the  messages  are  unpacked  into  PIMs  and 
distributed. 

•  Some  display  and  other  processing  is  performed  (such  as  flight  recorder  formatting  by  a  H009  GP). 

•  As  PIMs  are  received  from  current-frame  20  Hz  processes  in  the  VCC,  the  data  is  transferred  into 
messages  for  the  lOP  to  send. 

•  Current-frame  sub  20  Hz  data  is  packed  into  messages  for  the  lOP  to  send. 

The  following  are  some  of  the  major  feature  changes  that  are  tentatively  planned  for  the  F-15E  in  the  next 

five  years.  The  table  indicates  which  modules  will  probably  be  affected  by  the  upgrade,  and  the  breadth  of 

each  change. 


Upgrade  Feature 

A/A 

A/G 

C/D 

FD 

FR 

NAV 

SI 

EXEC 

UTIL 

Add  AIM-9X  A/A  Missile 

X 

X 

X 

X 

X 

Add  Helmet  Mounted  Cueing 
System 

X 

X 

X 

X 

X 

X 

X 

X 

Add  Combat  ID 

X 

X 

X 

Add  Joint  Stand  Off  Weapon 

X 

X 

X 

Add  Off-Board  Targeting 

X 

X 

X 

X 

X 

X 

Table  4.  VCC  Feature  Upgrade  Impact 

The  VCC  currently  uses  almost  all  of  its  throughput,  memory,  and  MUX  bandwidth.  Hardware  upgrades 
such  as  additional,  faster  DPMs  and  lOMs  will  be  necessary  to  support  the  feature  upgrades. 

As  stated  above  the  VCC  OFP  consists  of  five  primary  software  segments  (A,  B,  A1,  H1,  and  H2),  each 
consisting  of  processes,  resources,  and  sub-processes,  that  are  executed  on  one  of  five  cards  containing 
1750  processors.  The  following  table  shows  a  sample  characterization  of  the  processing  segments  and 
module  components  that  are  in  Segment  A  executing  on  processor  DPMI.  A  domain  model  was 
constructed  with  this  type  of  information  using  Cosmos™  to  prototype  approaches  to  VCC  upgrades  in 
terms  of  memory,  throughput,  and  Pi  Bus  backplane  usage  (via  Process  Interface  Messages,  PIMs). 

The  execution  of  the  VCC  OFP  can  be  characterized  as  follows: 

•  A  single  thread  per  processor. 

•  No  time  slicing,  no  preemption. 

•  No  other  tasks  executing  across  a  20  Hz  frame  boundary. 

•  Data  is  transferred  (pushed)  to  consumers  upon  completion  and  tasks  are  run  when  all  inputs  are 
ready  in  input  PIMs. 

•  All  output  data  is  copied  to  a  common  or  global  location  in  output  PIMs. 
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Model 

Process 

**  Application  Group  (Module) 

Execution 

(Processor  Capacity  =  3  MIPS) 

No. 

ID 

Segment 

Time  (ms) 

Max  Inst. 

Simulated 

Execution  /PIM  Notes 

1 

Y 

SI  20  Hz 

0.11 

330 

2 

N 

SP  Data  Distribution 

1.09 

3270 

Send  Message  1  to  HI 

3 

A 

Segment  A  Launch  Zones 

1.19 

3570 

Wait  for  Message  4  from  A1 

4 

N 

Engine  Monitor  20  Hz 

0.21 

630 

Send  Message  6  to  A1 

Wait  for  Message  7  from  HI 

5 

N 

Best  Avail  Nav 

6.33 

18990 

6 

N 

A/G  Target  Designator 

0.45 

1350 

7 

A 

20  Hz  Process 

6.93 

20790 

8 

D 

A/A  Radar  Control 

0.70 

2100 

9 

N 

SP  Management  20  Hz 

2.05 

6150 

10 

D 

A/G  Radar  Control 

1.14 

3420 

11 

D 

OWS  20  Hz 

1.51 

4530 

12 

D 

Jam  Cue  Control 

0.26 

780 

13 

D 

GCWS  OWS  20  Hz 

0.85 

2550 

14 

D 

HUD  Control 

0.29 

870 

15 

D 

TSD  Control 

0.32 

960 

16 

D 

Targeting  Pod  Control 

1.22 

3660 

Send  Message  2  to  B,A1  ,H1 

17 

D 

Display  Control 

7.14 

21420 

18 

X 

EXEC  20  Hz 

0.04 

120 

19 

x 

Complete  20  Hz  Processing 

0.18 

540 

20 

D 

OWS  10  Hz 

0.38 

1140 

21 

N 

UFC 

0.92 

2760 

22 

D 

GCWS  OWS  10  Hz 

1.41 

4230 

23 

x 

EXEC  10  Hz 

0.11 

330 

24 

N 

SP  Management  5  Hz 

0.33 

990 

Send  Message  3  to  A1 

25 

x 

EXEC  5  Hz 

0.02 

60 

26 

x 

EXEC  1  Hz 

1.60 

4800 

27 

B 

Self  Test 

0.77 

2310 

Totals 

37.55 

112650 

Table  5.  Example  of  DPMI  Processing  Tasks/TImes/lnstructlons  Model 
4.2.2  Characterize  Host 

The  upgrade  host,  the  ADCP,  essentially  replaces  both  the  VCC  and  MPDP  In  the  F-15  avionics  system 
VCC  context,  as  shown  In  the  following  figure.  The  electronic  Interface  between  mission  processing  and 
display  processing  In  the  ADCP  Is  via  a  VME  backplane  Instead  of  the  “Display  1553”  multiplex  bus.  The 
prototype  ADCP  used  for  the  demo  has  a  PowerPC  CPU  on  one  general-purpose  processor  (GPP)  as 
Illustrated  In  the  following  figure.  The  ADCP  OFP  Is  executed  on  the  GPP  processor  card. 
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Discrete  I/O  Serial  I/O  1553  Channels  Cockpit  Displays 


Figure  9.  ADCP  Processor  Configuration 


4.2.3  Host  OFP  Model 

The  ADCP  OFP  applications  are  written  in  C++.  The  ADCP  infrastructure  including  the  “main”  routine  is 
written  in  object-oriented  C++,  and  runs  above  a  VxWorks™  RTOS.  The  Flost  OFP  and  additional  features 
can  be  compiled  using  a  Green  Flills  MULTI™  (C++,  Ada,  etc.)  compiler.  Some  characteristics  of  the 
Host’s  execution  are  the  following: 

•  “Single  Processor  Event  Driven  Executive”  with  expansion  to  multiple  loosely  coupled  processors. 

•  Multiple  threads  per  processor. 

•  Higher  priority  threads  can  preempt  lower  priority  threads. 

•  A  20  Hz  task  must  complete  within  a  20  Hz  time  frame. 

•  A  10  Hz  task  may  cross  a  20  Hz  frame  but  must  complete  within  a  10  Hz  time  frame. 

•  A  task  is  “awakened”  when  its  inputs  are  available. 

•  A  task  retrieves  the  inputs  it  needs  by  calling  “get”  functions. 

One  way  to  characterize  the  Host  is  to  show  how  the  task  events  and  their  processes  (P)  are  scheduled. 
The  following  figure  contrasts  the  Scheduler  for  the  original  VCC  OFP  implementation  with  the  ADCP 
implementation. 


Figure  10.  Comparison  of  VCC  and  ADCP  OFP  Execution 

The  information  from  FODA  is  one  of  several  inputs  to  the  upgrade  design.  Performance  modeling  was 
performed  for  the  F-15  Project’s  upgrade  program  using  the  Nuthena  Foresight™  tool.  Extensive 
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measurements  were  made  on  the  Host  OFP  in  the  ADCP.  This  data  indicated  that  the  singie-processor 
ADCP  had  sufficient  throughput,  memory,  backpiane,  and  I/O  bandwidth  to  execute  a  reengineered  00 
OFP  with  spare  capacity  for  the  additionai  wrapped  upgrade.  Therefore,  additionai  domain  modeiing  was 
not  performed  for  this  case  study/demo.  It  is  highiy  recommended  that  architecturai  modeiing  be 
performed  for  more  compiex  upgrades  using  toois  such  as  HTC’s  MetaFF^,  especiaiiy  if  the  upgrade 
invoives  changes  in  the  software  topoiogy  (e.g.,  partitioning  the  processing  onto  muitipie  processors  or 
subsystems). 

4.2.3. 1  Selecting  the  Preferred  Upgrade  Candidate 

Severai  F-15  avionics  system  candidates  for  demonstrating  lULS  wrapper  technoiogies  were  identified 
inciuding  three  from  the  VCC  (one  hybrid  and  two  rehost)  and  one  from  the  MPDP.  The  best  candidates 
invoived  a  VCC  upgrade.  Part  of  the  rationaie  supporting  this  statement  is  that  at  the  time  of  seiection  of 
Task  2  F-15  demonstration,  the  F-15  project  was  considering  an  upgrade  to  the  VCC  with  the  objectives 
of: 

•  Mitigating  the  hardware  obsoiescence  of  the  1750  processors  and  other  components. 

•  Easing  the  VCC  capacity  restraints  to  aiiow  the  efficient  addition  of  new  functionaiity. 

•  Giving  the  VCC  capabiiities  to  expioit  Boeing’s  Common  OFP  reuse  components  for  additions 
and  upgrades. 

The  emuiator  approach  was  not  viabie  for  any  VCC  candidate.  The  resource  capacity  reiief  it  wouid 
provide  was  questionabie,  and  the  wrappers  required  to  interface  with  new  COFP  components  wouid  be 
costiy. 

The  first  candidate  for  a  iow  risk  yet  vaiuabie  demonstration  was  a  Hybrid  approach.  COFP  components 
wouid  be  added  to  a  new  GPM  as  was  demonstrated  during  the  initiai  Common  NAV  project.  For  the 
Hybrid  demonstration  the  R4400  GPM4  wouid  be  used  again  with  the  objective  of  adding  at  ieast  one 
moduie  from  the  Boeing  Common  OFP  reuse  iibrary.  The  modeiing/simuiation  performed  in  Task  1 
indicated  that  there  were  sufficient  resources  avaiiabie  to  accommodate  the  processing.  The  iegacy  OFP 
anaiysis  and  wrapper  buiiding  wouid  be  done  with  the  new  Task  2  tooi-set,  process,  and  framework.  The 
resuits  in  terms  of  engineering  cost,  wrapper  compiexity,  and  wrapper  performance  wouid  be  compared 
with  those  from  the  manuaiiy  generated  Common  NAV  wrapper  demo. 

Two  aiternative  VCC  demonstrations,  invoiving  a  rehost,  were  identified.  Again  they  had  appiication  to  F- 
15  avionics  configurations  which  wiii  not  be  fuiiy  upgraded  or  reengineered  yet  wiii  receive  an  ADCP-iike 
unit.  The  Task  1  pian  proposed  to  anaiyze  iegacy  OFP  components  on  aii  five  VCC  processors  and  to 
utiiize  the  lULS  toois  and  processes  to  merge  them  into  a  singie  component  to  be  executed  on  a  singie 
processor  card  in  the  ADCP.  As  part  of  the  Boeing/CDInt  R&D  project,  the  capabiiities  of  Ada83/95  target 
compiiers  and  the  execution  of  additive  ioads  on  a  COTS  processor  were  examined.  One  conciusion 
drawn  was  that  a  combined,  re-hosted  F-15  software  configuration  was  viabie  and  portabie  without 
reengineering.  The  ADCP  had  spare  siots  for  additionai  COTS  processors  that  couid  serve  as  hosts  for 
distributed  COFP  components  iinked  with  ORB  wrappers. 

Eariy  in  Task  2,  two  candidate  VCC  re-hosts  were  presented  to  the  F-15  and  lULS  customer.  In  the  first 
candidate,  the  abiiity  of  the  lULS  tools  to  wrap  legacy  components  for  reuse  in  a  modular  architecture  on 
an  OTS  processor  would  be  demonstrated.  In  this  case  the  Ada  83  Overload  Warning  System  (OWS) 
Module  from  VCC  Suite  3  would  be  integrated  into  the  C-r-i-  COSSI  Operational  Flight  Program  (COFP)  as 
illustrated  in  the  following  figure.  Task  2  activities  involved  in  this  re-host  included: 

•  Analyze  and  model  reuse  component  and  target  system 

•  Extract  multi-rate  OWS  Module  and  PIMs  from  VCC  DPMI  Segment  A 

•  Combine  OWS  components  using  Ada95,  and  enclose  with  wrapper  components  to 
interface  with  COFP. 
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Figure  11.  F-15  VCC  Rehost  Candidate  #1 

In  the  second  candidate,  the  abiiity  of  the  lULS  toois  to  rehost  a  iegacy  OFF  onto  a  new  OTS  processor 
wouid  be  demonstrated.  It  would  be  upgraded  with  COFP  reuse  components  from  the  Common  OFP 
Library  as  part  of  the  rehost.  This  is  a  more  challenging  case  in  which  two  wrappers  are  required  as 
illustrated  in  the  following  figure.  Wrapper  1  adapts  merged  Ada83  modules  and  PIMs  from  VCC  Suite  3. 
Wrapper  2  adapts  the  COFP  augmented  with  the  Navigation  Data  External  Environment  from  the  COFP 
Library.  Task  2  activities  involved  in  this  rehost  included: 

•  Analyze  and  model  legacy  OFP,  reuse  component,  and  target  system 

•  Extract  TBD  Ada83  modules  and  PIMs  from  Suite  3  VCC  OFP 

•  Combine  into  one  segment  using  Ada95,  and  enclose  with  wrapper  components  to  execute  on  one 
general  purpose  processor  (employ  COSSI  OFP  essentially  as  a  wrapper) 

•  Add/host  a  COFP  reuse  component  using  a  wrapper  including  infrastructure  and  ORB  (if 
necessary) 


F-15  Demo  Approach  #2 

Rehost  Legacy  OFP  And  Add  Reuse  Component 


VCC 


VMEbus 


Figure  12.  F-15  VCC  Rehost  Candidate  #2 

Early  in  Task  2,  Approach  #1  was  identified  as  the  preferred  approach  and  with  customer  concurrence  it 
was  selected  for  the  Task  2  F-15  Demonstration.  By  this  time  the  PowerPC  had  been  chosen  over  the 
R4400  as  the  upgrade  (target)  processor  due  to  availability  and  compliance  with  design  standards. 
Rational  governing  the  selection  of  Approach#1  included: 
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•  It  supported  evolution  to  a  C++  (COFP)  F-15  OFF  baseline  -  the  plan  (at  that  time)  was  to  evolve 
to  a  COFP  software  baseline  for  the  F-15 

•  It  exercised  all  elements  of  the  lULS  rehost  tool-set 

•  It  was  lower  risk  and  cost  than  Approach  #2  -  It  would  leave  sufficient  funding  to  pursue  a  C-17  lULS 
Demonstration  plus  other  lULS  transition  candidates. 

4.2. 3. 2  Characterize  Host  Upgrade 

A  number  of  upgrade  approaches  were  examined  by  the  F-15  Project  (and  subsets  were  considered  for 
the  lULS  demonstration)  including: 

1.  Recompile  the  entire  F-15  Ada83  OFP  for  the  new  Host  processor  and  rewrite/replace/wrapper 
any  code  necessary  to  operate  with  the  new  COTS  I/O,  backplane,  and  integrated  display  driver 
hardware.  (This  is  a  traditional  approach.) 

2.  Recompile  just  the  applications  (features)  and  rehost  them  on  a  new  COTS  Infrastructure,  real¬ 
time  operating  system  (RTOS)  and  hardware-interface  software  layers.  The  Infrastructure 
replaces  the  Executive  functionality  and  adds  ORB  multi-processing  capability,  allowing  the  OFP  to 
be  physically  partitioned.  The  applications  interface  to  the  lower  levels  with  wrappers/adapters. 

3.  Re-engineer  the  entire  OFP  in  an  object-oriented,  layered  architecture  (including  the  new 
Infrastructure,  RTOS  and  hardware-interface  layers),  drawing  common  feature  code  from  a  reuse 
library,  and  using  wrappers/adapters  to  adjust  interfaces. 

4.  Use  a  combination  of  2  and  3  and  take  advantage  of  the  multi-processor  Infrastructure  and  RTOS: 
After  re-establishing  the  feature  baseline  on  the  new  Host,  add  new  00  features  to  another  OFP 
partition  or  other  processors,  drawing  from  a  reuse  library. 

All  approaches  could  use  lULS  technology  to  some  extent,  but  all  would  be  very  large-scale  efforts.  The 
F-15  Project  took  Approach  3  to  re-engineer  a  subset  of  Production  F-15  OFP  functionality  and  run  on  the 
new  ADCP  as  part  of  the  “COSSI”  R&D  program 

A  limited  version  of  Approach  4  was  chosen  for  the  lULS  OWS  Demonstration  since  it  fit  within  the  scope 
of  the  project  yet  exercised  most  of  the  lULS  technology  in  a  realistic  scenario  on  a  real  avionics  platform. 
It  illustrates  how  a  new  feature  designed  with  one  language  and/or  architecture  can  be  merged  in  a  host 
with  a  different  language/architecture  using  a  multi-lingual  wrapper.  Multi-lingual  OFPs  are  starting  to  be 
used  in  mission-critical  systems.  They  can  make  efficient  use  of  multi-lingual  reuse  libraries,  and  are  made 
possible  in  part  by  new-generation  multi-lingual  system/software  development  tools  (such  as  Rational 
Rose™  and  Green  Hills  MULTI™),  and  languages  (such  as  Ada95  with  built-in  interfaces  to  other 
languages). 

4.2. 3. 3  Selecting  the  Preferred  Wrapper  Approach 

Since  the  OWS  upgrade  is  more  than  a  re-host/re-compile  of  the  OWS  software  on  another  hardware 
system  it  is  classified  as  a  hybrid  upgrade  with  the  OWS  function  in  a  new  software  partition  formed  with  a 
wrapper.  The  ADCP/OFP  combination  was  a  convenient  demonstration  Host  onto  which  the  additional 
upgrade  feature  could  be  “wrapped”.  The  performance  goals  of  the  demo  were  simply  to  reproduce  the 
OWS  behavior  and  have  the  worst-case  path  of  the  new  system  execute  within  the  required  20  Hz  frame 
rate.  This  was  judged  to  be  possible  based  on  performance  modeling  of  OWS  within  the  VCC  OFP, 
worst-case  measurements  of  the  baseline  Host  OFP  (with  spare  capacity),  and  estimates  of  the  execution 
of  the  wrapper  derived  from  a  preliminary  WrapidH  model. 

For  the  Host  “COSSI”  OFP,  a  subset  of  the  VCC  OFP  features  were  re-engineered  or  implemented  with 
components  from  the  Boeing  Common  Software  Reuse  Library  (such  as  the  Infrastructure/ORB)  providing 
a  baseline  upgraded  Host  software  environment.  The  Overload  Warning  System  feature  was  picked  as  an 
additional  upgrade  feature  because  it  is  unique  to  the  F-15  and  not  available  from  a  reuse  library.  OWS 
source  code  from  VCC  OFP  Segments  on  DPMI  and  DPM2  were  ported  to  the  ADCP  GPP. 

The  OWS  function  consists  of  a  series  of  calculations  that  transform  the  inputs  (primarily  weapon  and  fuel 
load  and  flight-state)  into  the  overload  warning  outputs  including  cockpit  display  features.  The  software 
interface  to  the  legacy  OWS  function  consists  of  a  series  of  process  interface  messages  (PIMs)  and 
Critical  Load  Data  (CLD).  The  OWS  function  and  associated  PIMs  and  CLDs  are  written  in  Ada  and  can 
be  compiled  by  an  Ada95  compiler.  Their  memory  layout  is  fixed  by  Ada  representation  specifications. 
The  OWS  function  assumes  that  the  PIMs  are  updated  by  the  Infrastructure  before  it  is  called.  This 
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assumption  constitutes  a  timing  dependency  and  a  push  data  fiow  architecture. 

In  the  legacy  F-15  host,  the  infrastructure  around  the  OWS  function  consists  of  a  software  executive  layer 
(EXEC)  running  on  each  processor  module.  The  32-bit  Parallel  Interface  (PI)  bus  transfers  PIMs  and 
CLDs  between  the  various  functions  in  the  distributed  processing  system. 

The  overall  sequence  of  events  within  the  DPM  processing  was  shown  in  Table  5  for  both  the  OWS  20  Hz 
and  10  Hz  cycles.  The  queued  message  and  OWS  components  were  shown  in  bold.  The  timing  data  can 
be  characterized  as  performance  data,  however  the  main  issue  is  not  to  improve  the  performance  but  to 
be  able  to  re-use  the  OWS  code  and  have  it  run  correctly  and  reduce  the  development  and  testing  effort. 

There  are  obviously  many  differences  between  the  legacy  VCC  hardware  and  its  software  architecture  and 
the  new  Host  processor.  The  VCC/OWS  was  a  single  thread-per-process  but  multi-process  system 
running  on  multiple  loosely  coupled  processors.  The  target  is  a  multi-threaded  multi-process  system 
typical  of  the  latest  real-time  mission  processors.  A  control  and  data  adapter  was  necessary  to  make  use 
of  the  existing  OWS  code  intact  yet  make  it  work  within  the  new  processing  environment. 

Subsequent  to  selecting  the  problem  domain  to  be  addressed  in  the  lULS  F-15  Demonstration,  a  multi-step 
process  was  used  to  execute  the  program.  The  F-15  OWS  Demonstration  process  is  shown  in  the 
following  figure.  Key  features  include: 

•  Continuation  of  the  Task  1  Domain  Analysis  through  the  Task  2  Wrapper  Generation 

•  Development  of  the  WrapidH  Tool  using  the  Honeywell  Domain  Modeling  Environment  (DoME) 

•  Wrapping  the  F-15  Ada  OWS  Functionality  and  integrating  it  into  the  COFP 

•  Validation  of  the  Wrapped  Software  using  F-15  Simulation  Tools 

•  Live  Flight  Demonstration  of  the  Validated  Product 
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Figure  13.  F-15  OWS  Demonstration  Process 

4.3  Designing  the  Wrapper 

As  identified  in  Task  1  and  shown  in  the  following  figure,  the  general  framework  of  the  Rehost  wrapper 
architecture  is  largely  independent  of  the  technique  used  in  an  upgrade.  The  wrapper  services  associated 
with  the  rehost  mode  are  as  follows: 

•  Wrapper  Initialization 

•  Wrapper  control  -  the  wrapper  process  executes  as  a  task  of  the  host  Executive 

•  Process  and  data  synchronization 

•  Interrupts  and  Synchronization 

•  Clock  services 

•  Shared  data  access 
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•  “Get”  -  access  to  legacy  memory  space  by  a  process 

•  “Put”  -  move  data  to  legacy  memory  space 
•  External  data  access 

•  Input  handler 

•  Output  handler 


Data  Gateway 


Get/Put 


I/O  Data  Flow 


Drivers/Reformat 


Legacy  OFP 
Memory 
Space 

Wrapper 

Interface 


Hybrid  Processor 


Events 


Sync/Timers/ 

Controls/Reset 


Figure  14.  Generic  Rehost  Wrapper  Architecture 

For  the  selected  demonstration,  the  Legacy  OFP  Includes  three  Ada83  functional  threads,  as  shown  In  the 
following  figure.  These  threads,  execute  at  specified  rates  under  control  of  the  Ada  executive  and  draw 
their  Inputs  from  other  Ada  threads  through  the  “PIMs”  shown  In  the  figure.  Each  PIM  represents  one  or 
more  data  Items  used  by  the  three  OWS  threads.  The  Interface  from  the  OWS  threads  to  the  other  Ada 
threads  Is  through  the  three  output  “PIMs”  shown  In  the  figure.  There  Is  a  one-to-one  relationship  between 
the  threads  and  the  similarly  named  output  PIM.  The  challenge  for  the  demonstration  is  to  develop  the 
“Wrapper  Interface”  which  Integrates  this  Legacy  OFP  Into  the  C-r-i-  COFP.  In  order  to  accomplish  this, 
each  of  the  Rehost  wrapper  services  listed  above  must  be  supplied. 
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INPUTS 

From  Other  Thi'eads 
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D_AFCS_20_HZ_INPUT_PIM 
•Flight  Control 
D_AIU_20_HZ_INPUT_PIM 
•Avionics  Interface  Unit 
D_GEN_10_HZ_UNPACK_PIM 
•Aircraft  Stores 

D_GEN_20_HZ_UNPACK_PIM 
•Discretes _ 

D_HUD_CONTROL_PIM 
•AO A  Limit 

D_INS_20_HZ_INPUT_PIM 
•INS  Data 

D_MPDP_20_HZ_INPUT_PIM 
•MPDP  Outputs 
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Figure  15.  OWS  Structure 

After  several  potential  wrapper  approaches  were  explored,  the  resulting  top-level  wrapper  design 
employed  a  combination  of  C-f-i-  and  Ada95  code.  The  C-f-i-  components  communicate  with  Flost  C-f-i- 
OFP,  and  the  Ada  components  are  used  to  communicate  with  the  legacy  OWS  Ada83.  One  objective  that 
was  satisfied  by  this  approach  was  to  leave  both  the  new  host  and  OWS  legacy  code  unchanged.  An 
example  of  the  data  transforms  and  conversions  that  are  necessary  in  the  wrapper  implementation  for  one 
of  the  OWS  functions  is  shown  in  the  following  figure. 


C++ - 4* - Ada 


Figure  16.  Typical  Data  Transform  for  Preliminary  Wrapper  Design 


The  remainder  of  this  section  discusses  detailed  solutions  for  each  of  the  wrapper  services  to  this  top-level 
design.  The  first  subsection  discusses  initialization  issues  including  Ada  elaboration.  The  second 
subsection  discusses  scheduling  issues  associated  with  execution  of  the  OWS  Functional  Threads  under 
the  Event  Sequencer  chosen  for  the  Object  Oriented  COFP.  The  next  subsection  addresses  Process  and 
Data  Synchronization.  For  the  OWS  demonstration,  there  was  little  demand  in  this  area.  The  next 
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subsection  addresses  shared  data  access.  This  was  the  major  focus  of  the  OWS  demonstration  and 
much  detaii  regarding  the  soiution  is  presented.  Finaiiy  Externai  Data  Access  is  discussed. 

4.3.1  Wrapper  Initialization 

The  OWS  Demonstration  presented  two  initiaiization  chaiienges:  Ada  Eiaboration  and  Execution  of  OWS 
First  Pass  Logic.  Eiaboration  is  needed  to  initiaiize  the  various  Ada  OWS  PIMs,  which  are  incorporated 
inside  the  wrapper.  Using  WrapidH,  an  Ada  INITIALIZE. PIM  procedure  was  created  to  Elaborate  the 
PIMs  used  by  the  OWS  logic.  In  addition,  Ada  logic  was  created  to  initialize  flags,  which  needed  to  be 
stubbed,  as  discussed  under  the  topic  ‘Access  required  from  functions  not  yet  available  in  the  COFP  “ 
below.  This  stub  initialization  logic  was  also  incorporated  into  the  Ada  INITIALIZE. PIM  procedure.  The 
C++  procedure,  which  executes  the  OWS  20HZ  logic,  was  designed  to  call  the  Ada  initialization  procedure 
on  the  first  execution  pass. 

4.3.2  Wrapper  Control 

The  F-15  lULS  Demonstration  required  integrating  three  legacy  functional  threads, 
PERFORM_OWS_10_HZ,  PERFORM_OWS_10_HZNZ_WARN,  and  PERFORM_OWS_20_HZ  into  the 
Event  Sequencer  structure  used  for  controlling  the  execution  of  objects  in  the  COFP.  Factors  considered 
in  designing  the  Wrapper  Control  included: 

•  Tolerances  in  the  rate  at  which  each  functional  thread  is  executed 

•  Tolerances  in  the  latency  of  execution  of  each  thread 

•  Pre-requisites  for  execution  of  each  task 

•  Input  data  coherency  requirements 

•  Output  data  coherency  and  dependency  requirements. 

4.3.2. 1  Tolerances  In  the  Rate  At  Which  Each  Functional  Thread  Is  Executed 
Program  designs  generally  have  a  minimum  rate  at  which  a  thread  must  be  executed  but  rarely  have  a 
hard  limit  on  the  maximum  rate.  In  general,  the  maximum  rate  is  limited  only  to  maintain  computer  resource 
margins.  A  design  in  which  the  minimum  rate  is  guaranteed  and  the  maximum  rate  is  allowed  to  rise,  given 
excess  resource  reserves  is  generally  acceptable  and  is  even  desirable  if  the  increased  rate  of  execution 
tends  to  improve  the  overall  utility  of  the  system. 

For  the  lULS  OWS  Demonstration,  analysis  of  the  legacy  code  indicated  that  the  true  scheduling  driver  for 
the  OWS_10_HZ  and  OWS_1 0_HZ_NZ_WARN  tasks  is  that  they  execute  at  least  10  times  per  second  but 
a  higher  rate  would  be  acceptable.  The  10  hertz  rate  was  originally  chosen  to  enable  timely  execution 
subsequent  to  a  change  in  vehicle  configuration  such  as  release  of  stores  or  weight  off  wheels.  Since  the 
computations  involved  are  relatively  insensitive  to  vehicle  dynamics,  minimizing  the  delay  between  sensor 
inputs  and  OWS  computations  was  not  a  design  driver.  The  OWS_20_FIZ  rate  was  selected  to  take 
advantage  of  the  rate  of  input  of  CAE  Normal  Acceleration.  Again  maintaining  the  exact  rate  was  not  seen 
as  critical.  A  20  FIZ  rate  ensures  that  the  peak  loads  measured  by  OWS  are  representative  of  aircraft 
loading.  This  is  important  from  both  a  flight  safety  and  maintenance  viewpoint.  Flowever,  capturing  the 
exact  peak  load  is  not  considered  critical.  Again,  a  20  FIZ  or  higher  rate  of  execution  was  deemed 
acceptable. 

4.3. 2. 2  Tolerances  In  The  Latency  Of  Execution  Of  Each  Thread 

Older  designs,  optimized  for  efficiency,  sometimes  utilize  numerical  integration  techniques  in  which  the  time 
interval  has  been  “hard  wired”  into  the  code  or  into  numerical  coefficients.  In  these  designs,  inaccuracies  in 
the  execution  interval  produce  proportional  errors  in  the  integration  accuracy.  Most  modern  designs  are 
tolerant  to  variations  in  the  interval  between  thread  executions.  Analysis  of  the  OWS  design  indicated  that 
there  is  negligible  sensitivity  to  variations  in  the  period  between  thread  execution. 

4.3. 2. 3  Pre-requisites  For  Execution  Of  Each  Task 

In  general,  it  is  desirable  to  have  a  thread  execute  when  a  coherent  new  set  of  inputs  becomes  available. 
This  can  be  accommodated  by  delaying  initiation  of  the  thread  until  all  requisite  inputs  are  available  or  by 
employing  logic  which  delays  portions  of  the  execution  until  the  requisite  inputs  become  available.  In  the 
OWS  design,  the  task  structure  was  developed  to  ensure  that  requisite  critical  coherent  data  was  available 
before  initiation  of  each  thread.  For  the  OWS_10_HZ  task,  current  INS  data  is  required  as  well  as  the 
most  recent  Air  Vehicle  Configuration  (stores).  The  OWS_1 0_HZ_NZ_WARN  thread  should  execute  when 
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the  latest  INS,  AFCS  and  ADP  data  are  available.  It  should  also  execute  after  the  OWS_10_HZ  thread  Is 
complete.  The  OWS_20_HZ  task  should  also  execute  when  the  latest  INS,  AFCS  and  ADP  data  are 
available.  It  should  also  follow  the  OWS_10_HZ_NZ_WARN  thread. 

4.3. 2.4  Output  Data  Coherency  And  Dependency  Requirements 

Execution  control  may  also  be  dictated  by  the  needs  of  other  threads,  which  use  the  outputs  of  the  thread 
being  scheduled.  In  the  OWS  case,  the  outputs  drive  displays  and  cockpit  voice.  The  Ada  OFP  design  Is 
such  that  the  OWS  processing  Is  completed  before  the  display  and  voice  generation  processing  Is  entered 
and  the  display  and  voice  generation  complete  before  the  start  of  the  next  OWS  cycle.  Since  there  Is  no 
possibility  of  the  display  or  voice  generation  functions  Interrupting  the  OWS  threads  or  vice  versa,  output 
data  coherency  Is  not  an  Issue.  However,  In  the  event  driven  executive  scheme  used  for  the  COFP,  It 
could  become  an  Issue  If  the  display  generation  were  partially  complete  when  the  requisite  events  for  the 
next  execution  of  an  OWS  thread  were  satisfied.  In  this  case  the  display  and/or  voice  generation  function 
might  be  Interrupted  after  a  partial  output  and  complete  with  refreshed  (non-coherent)  data.  For  the 
demonstration,  this  was  considered  to  be  of  such  low  probability  that  It  was  neglected.  In  an  eventual 
operational  event-driven  OFP  Implementation,  It  might  be  best  to  Implement  a  display  complete  event  as 
part  of  the  OWS  thread  trigger  mechanism.  Again  significant  systems  engineering  effort  would  be  required 
before  such  a  design  would  be  pursued. 

4.3. 2. 5  Control  Implementation  for  the  lULS  Demonstration 

The  Wrapper  Execution  Control  design  chosen  for  the  lULS  demonstration  featured  the  following: 

•  The  PERFORM_OWS_10_HZ_Wrapper  thread  should  be  executed  whenever  an  INS  event  occurs. 
Because  the  COFP  hardware/software  configuration  used  for  the  demonstration  had  no  capability  for 
sensing  changes  In  the  aircraft  external  stores  configuration,  all  stores  data  for  the  demonstration  were 
stubbed,  and  therefore  no  attempt  was  made  to  tie  execution  of  this  task  to  changes  In  the  external 
stores  configuration. 

•  The  PERFORM_OWS_10_HZ_NZ_WARN_Wrapper  should  be  executed  whenever  an  INS,  AFCS  and 
ADCP  event  has  occurred  and  the  PERFORM_OWS_10_HZ_Wrapper  has  completed. 

•  The  PERFORM_OWS_20_HZ_Wrapper  should  be  executed  whenever  an  INS,  AFCS  and  ADCP  event 
has  occurred  and  the  PERFORM_OWS_10_HZ_NZ_WARN  Wrapper  has  completed. 

PERFORM_OWS_20_HZ_Wrapper  executes  each  time  PERFORM_OWS_10_HZ_NZ_WARN  Wrapper 
completes  and  both  of  the  10  HZ  tasks  execute  at  a  higher  rate  than  In  the  Ada  design.  No  attempt  was 
made  to  reduce  the  rate  of  execution  of  any  task  In  order  to  conserve  computational  resources.  This 
design  Is  considered  adequate  for  the  purpose  of  the  demonstration.  However,  for  an  operational 
capability,  a  more  detailed  systems  engineering  effort  would  be  required  to  consider: 

•  Computational  load  associated  with  each  task 

•  Computational  resource  allocation  to  OWS  processing 

•  True  requirements  regarding  minimum  rate  of  execution  of  each  task  and  maximum  latency  between 
requisite  Inputs  and  associated  OWS  task  completion. 

Ultimately  a  design  that  reduces  the  rate  of  execution  of  each  of  the  OWS  tasks,  might  be  preferred.  This 
could  be  accommodated  through  Introduction  of  events,  which  occur  based  on  periodicity  or  by  logic  which 
executes  the  OWS  10  HZ  threads  on  a  subset  of  the  INS  events.  Analysis  of  and  response  to  these  types 
of  Issues  were  considered  beyond  the  scope  of  the  lULS  Program.  They  are  common  to  all  event-oriented 
scheduling  schema  Including  new  starts  as  well  as  attempts  to  utilize  legacy  software. 

4.3.3  Process  And  Data  Synchronization 

For  the  OWS  wrapper  demonstration,  there  were  no  Interrupts  or  Clock  Service  Issues  to  deal  with.  Data 
synchronization  Issues  were  easily  addresed  under  the  COFP  Event  Structure.  As  related  In  the  previous 
section,  availability  of  coherent  sets  of  INS,  AFCS  and  ADCP  data  was  used  to  trigger  the  appropriate 
OWS  threads.  Task  1  analysis  of  the  F-15  re-host  problem  Indicated  that  considerable  excess  throughput 
was  available  on  the  COTS  process  chosen.  Given  this  resource  excess,  there  was  no  problem 
completing  OWS  processing  before  the  next  data  Input  sequence.  This  excess  capacity  was  confirmed 
through  system  testing  executed  prior  to  the  flight  demonstration. 
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4.3.4  Shared  Data  Access 

Shared  data  access  was  by  far  the  most  important  issue  in  deveioping  the  OWS  Demonstration.  Shared 
data  access  issues  feii  into  four  categories: 

•  Access  to  data  avaiiabie  from  COFP  eiements 

•  Access  required  from  functions  not  yet  avaiiabie  in  the  COFP 

•  Output  of  data  from  the  OWS  threads  back  to  the  COFP 

•  Type  conversions 

4.3.4. 1  Access  To  data  Available  From  COFP  Elements 

The  first  activity  executed  in  designing  the  OWS  Wrapper  was  the  mapping  of  each  eiement  in  the  OWS 
Input  PIMs  back  to  an  “Accessor”  Function  on  the  COFP.  This  is  the  most  compiex  and  iaborious  task  in 
wrapper  design.  Aii  of  the  OWS  inputs  and  outputs  must  be  accounted-for  and  anaiyzed  by  an  OWS 
domain  expert.  For  the  case  study,  an  Ada  program  anaiyzer/parser  was  used  to  iist  aii  of  the  parameters 
in  the  OWS  input  and  output  PIMs  and  in  the  processing.  The  tooi  aiso  provides  a  iist  of  dependencies  - 
supporting  components  in  the  Legacy  OFP  that  were  imported.  Each  parameter  was  characterized  in 
terms  of  function,  format  and  timing.  Parameters  that  interfaced  with  the  Host  were  mapped  to  equivaient 
Host  parameters  and/or  marked  for  unique  wrapper  component  design  (transforms,  stubs,  etc.). 

The  methodoiogy  used  to  match  C++  accessors  back  to  Ada  variabies  was  to  use  utiiities  such  as  the  Unix 
“grep”  command  to  search  the  COFP  Library  for  matches  with  Ada  variabie  names  or  partiai  names.  In 
general  multiple  matches  were  found  and  required  further  analysis  to  identify  which,  if  any,  of  the  matches 
were  appropriate.  Lessons  were  learned  resulting  from  this  activity.  Programming  standards  used  in 
developing  a  new  version  of  software  should  force  a  level  of  consistency  in  naming  standards  between 
legacy  and  new  versions.  This  would  enable  more  efficient  “key  word”  searches  in  order  to  match  required 
data  to  sources.  Given  an  enforced  level  of  naming  consistency,  a  generalized  tool  could  be  developed  to 
automate  much  of  the  data  matching  activity.  Unfortunately,  naming  consistency  from  the  Ada  OFP  to  the 
COFP  was  not  required,  making  the  generation  of  the  data  map  far  more  laborious.  Furthermore,  the  map 
was  generated  by  personnel  who  were  unfamiliar  with  OWS  function,  making  the  process  more  laborious. 
Domain  experts  were  in  short  supply  and  were  available  only  to  review  and  finalize  the  product.  Despite 
these  challenges,  the  wrapper  was  developed  on  a  schedule,  which  preceded  the  availability  of  the  test 
aircraft. 

A  mapping  from  the  F-15  COFP  to  the  F-15  OWS  PIMs  was  developed  to  document  the  results  of  these 
searches.  An  excerpt  of  the  final  version  is  presented  in  the  following  table,  and  the  full  table  is  in 
Appendix  A.  This  mapping  served  as  the  primary  requirement  for  developing  the  OWS  Wrapper.  Using 
WrapidH,  we  were  able  to  directly  implement  these  requirements  graphically  and  the  requisite  code  was 
automatically  generated.  Although  some  effort  was  spent  developing  and  debugging  the  WrapidH 
capability,  the  recurring  effort  involved  in  converting  a  similar  table  into  functioning  Ada  and  C++  code  will 
be  minimal.  The  left-hand  column  of  the  table  contains  the  OWS  Ada  PIM  name.  The  middle  column 
contains  the  Ada  variable  name  and  Ada  type.  The  right  hand  column  contains  the  COFP  file  name  and 
line  number,  the  access  methodology  and  the  return  arguments  and  types. 
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F-15  OWS  PIM 

F-15  COFP 

D_ADC_20HZ_INPUT_PIM 

MACH_NUMBER  :  Mach; 
type  Mach  is  new  Real  range  - 
20.0  ..  20.0; 

A5ADP.h{57):  const  BQualityDouble&  GetMach(); 

Ex.  TheA5ADP_Ptr->GetMach() 

Returns  reference  to  BqualityDouble  -  GetValue()  returns 
mach/double/dimensionless,  lsValid()  returns  bool. 

D_ADC_20HZ_INPUT_PIM 

LOCAL_ANGLE_OF_ATTACK 
:  Cockpit_Units; 

type  Cockpit_Units  is  new  Real; 

A5ADP.h(56):  const  BAnglePiOver2& 

GetLocalAngleOf  AttackO ; 

Ex.  TheA5ADP_Ptr_->  GetLocalAngleOfAttack().GetAngle{) 
Returns  reference  to  BAnglePiOver2  - 
BaglePiOver2  derived  from  class  Bangles  -  GetAngle()  returns 
Local  Angle  Of  Attack/double/radians  limited  to -Pi/2  to  Pi/2. 

D_ADC_20HZ_INPUT_PIM 

LOCAL_ANGLE_OF_ATTACK 

VALID  :  Boolean; 

A5ADP.h(56):  const  BAnglePiOver2& 

GetLocalAngleOfAttackO; 

Ex.  TheA5ADP_Ptr_->  GetLocalAngleOfAttack{).lsValid() 

Returns  reference  to  BAnglePiOver2  - 

BaglePiOver2  derived  from  class  Bangles  -  lsValid()  returns 

bool 

Table  6.  OWS/COFP  Mapping 

The  top-level  data  processing  design  is  illustrated  in  the  following  figure,  with  the  black  or  dark  lines 
showing  the  data  flow  between  host,  wrapper,  and  legacy  OWS.  As  OWS  processes  are  being  run  they 
require  data  which  has  been  produced  in  the  Host  and  is  generally  pulled  by  the  wrapper.  This  data  must 
be  converted  to  a  form  required  by  OWS  input  PIMs.  The  data  that  is  computed  by  OWS  is  in  its  output 
PIMs  and  if  needed  by  the  Host,  is  pulled  and  converted/equivalenced  by  the  wrapper,  then  pulled  by  the 
Host  when  it  is  needed  for  display  at  the  end  of  the  processing  frame. 


Figure  17.  OWS  Wrapper  Architecture 

4.3.4. 2  Access  Required  From  Functions  Not  Yet  Available  In  COFP 
The  effort  to  map  the  OWS  Ada  PIM  variables  to  COFP  accessor  functions  yielded  numerous  variables  for 
which  no  accessor  exists.  In  most  cases  this  was  due  to  the  nature  of  the  COFP,  i.e.  it  is  a  partial 
implementation  of  the  F-15  requirements.  For  these  cases,  stub  values  were  specified  for  use  in  the 
demonstration,  most  stubs  were  implemented  as  fixed  values.  However,  some  “stubs”  deal  with 
peculiarities  of  the  OWS  Flight  Test  configuration.  During  the  test,  it  was  necessary  to  trigger  numerous 
overload  situations.  Obviously,  flight  safety  concerns  dictate  that  the  aircraft  not  be  stressed  in  this  way. 
The  solution  was  to  “lie”  to  the  software.  The  aircraft  flown  was  a  clean  configuration,  i.e.,  no  external 
stores,  no  fuel  in  the  conformal  tanks  (CFTs)  and  fuel  weight  decreasing  as  the  flight  progresses  (takeoff 
was  with  full  fuel).  However,  the  software  was  told  that  external  stores  were  present,  the  CFTs  were  fully 
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fueled  and  the  aircraft  internal  fuel  weight  was  constant.  Since  it  was  desired  to  test  several  points  in  the 
flight  envelope,  the  PACS  Training  Mode  capability  was  used  to  set  various  “simulated”  stores 
configurations  during  the  flight.  In  this  mode  the  crew  can  alter  the  stores  configuration  of  each  wing 
station  and  the  software  will  add  in  the  eight  of  the  “simulated”  bomb  and  rack  load.  It  was  also  desired  to 
vary  the  fuel  load  as  part  of  the  test  point  matrix.  In  response  the  wrapper  was  designed  to  extract  the 
fuel  load  based  on  pilot  inputs  through  the  cockpit  display  scratch-pad.  In  the  remaining  cases,  system 
design  decisions  made  for  the  COFP  resulted  in  an  implementation  for  which  there  is  no  direct  output 
available  to  satisfy  the  OWS  need.  For  these  cases,  logic  was  implemented  to  convert  COFP  parameters 
into  the  information  required  by  the  OWS  code.  An  example  of  this  is  the  logic  implemented  to  determine  if 
an  IPE  Engine  is  installed.  The  logic  implemented  checks  to  see  if  the  right  engine  is  type  PW229  and  the 
left  engine  is  type  PW229.  If  both  are  PW229,  “IPE  Engine  Installed”  is  set  true,  otherwise  it  is  false. 
Another  example  is  the  use  of  INS  acceleration  in  place  of  CAU  Normal  Acceleration  (CAU  inputs  were  not 
available  in  the  demo  configuration.  The  following  table,  in  format  similar  to  the  previous,  presents  a 
sample  of  the  results  of  this  ’’stubbing”  process  including  the  pilot  stores  and  fuel  weight  entry  capabilities. 
The  full  table  is  in  Appendix  B. 


F-15  0WS  PIM 

F-15  COFP 

D  GEN  10HZ  UNPACK  PI 

M 

BRU_STATION_WEIGHT : 

D_0  ws_T  y  pes .  Sta_2_8_5_Array_T  y  pe ; 

type  Sta_2_8_5_Array_Type  Is  array 

(Sta  2  8  5  L  R  TyperanqeSta  2..Sta  5)  of 

U_Baslc_Data_Types.  Pounds; 

type  Sta  2  8  5  L  R  Type  Is  (Sta  2,  Sta  8,  Sta  5,  Left, 

Reft); 

type  Pounds  Is  nevy  Real; 

Not  available  In  demo  eonfiguratlon  - 
Use  PACS  training  Capability 

If  (A5UPACS_Statlon.statlons[STA_X] 
.merPresent)  Stub  to 
BRU_STATION_WEIGHT(STA-X)  =  0 
lbs,  else 

BRU  STATION  WEIGHT(STA-X)  = 

524.0  lbs  for  X=2,5,8 

D  GEN  10HZ  UNPACK  PI 

M 

CFT_STATUS_FLAG  :  Cft_Type; 
type  Cft  Type  Is  (None,  Cft  4,  Cft  3); 

Not  available  In  demo  eonfiguratlon  - 
Stub  to  CFT  STATUS  FLAG  =  CFT  4. 

D  GEN  10HZ  UNPACK  PI 

M 

AG_WEAPON_COUNT : 

D_Ows_T  ypes.  Ag_Weapon_Cou  nt_Array_T  ype; 
type  Ag_Weapon_Count_Array_Type  Is 
array  (Sta  2  8  5  L  R  Type)  of 

U_Nu  mber_T  ypes.  lnteger_Short; 

type  Sta  2  8  5  L  R  Type  Is  (Sta  2,  Sta  8,  Sta  5,  Left, 

Reft); 

type  Integer  Short  Is  range -32768  ..  32767; 

Not  available  In  demo  eonfiguratlon  - 
Use  PACS  training  Capability 

Stub  to 

AG_WEAPON_COUNT(STA_X)  = 
A5UPACS_Statlons.statlons[STA_X] 
.wpnCount  for  X=2,5,8 

D  GEN  10HZ  UNPACK  PI 

M 

LAUNCHER_WEIGHT  : 

D_Ovys_T  y  pes .  Sta_2_8_Array_T  y  pe ; 

type  Sta_2_8_Array_Type  Is  array 

(Sta  2  8  5  L  R  Type  range  Sta  2. .Sta  8)  of 

U_Basle_Data_Types.  Pounds; 

type  Sta  2  8  5  L  R  Type  Is  (Sta  2,  Sta  8,  Sta  5,  Left, 

Reft); 

type  Pounds  Is  new  Real; 

Not  available  In  demo  eonfiguratlon  - 
Stub  to  LAUNCHER  WEIGHT(STA  2) 

=  LAUNCHER_WEIGHT(STA_8)  =  0 
lbs.  Note 

LAUNCHER_WEIGHT(STA_5)  Is  not 
defined. 

D  GEN  10HZ  UNPACK  PI 

M 

PYLON_WEIGHT : 

D_Ows_T  y  pes .  Sta_2_8_5_Array_T  y  pe ; 

Type  Sta_2_8_5_Array_Type  Is  array 

(Sta  2  8  5  L  R  Type  range  Sta  2. .Sta  5)  of 

U_Basle_Data_Types.  Pounds; 

Type  Sta  2  8  5  L  R  Type  Is  (Sta  2,  Sta  8,  Sta  5,  Left, 
Reft); 

Type  Pounds  Is  new  Real; 

Not  available  In  demo  eonfiguratlon  - 
Use  PACS  training  Capability 

If  (theA5UPACS_ptr- 
>GetPylonPresentSta2())  Stub  to 

PYLON  WEIGHT{STA  2)  =  500.0; 

Else  PYLON  WEIGHT(STA  2)  =0.0; 

If  (theA5UPACS_ptr- 
>GetPylonPresentSta5{))  Stub  to 

PYLON  WEIGHT(STA  5)  =  300.0; 

Else  PYLON  WEIGHT{STA  5)  =0.0; 

If  (theA5UPACS_ptr- 
>GetPylonPresentSta8())  Stub  to 

PYLON  WEIGHT{STA  8)  =  500.0; 

Else  PYLON  WEIGHT(STA  8)  =0.0; 

Table?.  OWS/COFP  Stubs 

4.3.4. 3  Output  Of  Data  From  OWS  Threads  Back  To  COFP 

The  OWS  functions  provide  overload-warning  indications  to  the  crew.  Outputs  from  the  OWS  threads 
back  to  elements  of  the  COFP  drive  these  displays.  For  the  demonstration  effort  was  required  to  convert 
the  Ada  output  back  to  the  C-i-i-  format,  to  implement  the  requisite  OWS  displays  and  voice  warnings.  The 
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displays  were  implemented  using  the  VAPS  tools.  The  remaining  output  capabilities  were  developed  using 
WrapidH. 

4.3.4.4  Type  Conversions 

Type  conversion  from  C++  to  Ada  was  required  for  the  parameters  passed  to  the  Ada  threads  and  from 
Ada  to  C++  for  the  display  and  voice  warning  parameters.  The  bulk  of  the  required  conversions  were 
implemented  using  the  WrapidH  tool  to  access  previously  developed  type  conversions.  This  process  was 
straight  forward  and  required  little  if  any  re-coding.  Two  problems  arose.  The  first  and  most  significant 
problem  was  the  conversion  of  arrays.  There  is  no  capability  to  pass  an  array  by  value  to  or  from  C++. 
C++  treats  arrays  through  pointers.  Extracting  or  supplying  pointers  is  not  compatible  with  Ada  principals. 
The  only  solution  to  this  problem  was  to  develop  routines,  which  passed  arrays  back  and  forth  on  an 
element  by  element  basis.  The  second  problem  was  an  Ada  exception,  which  was  experienced  in  the 
laboratory  test  environment.  The  problem  occurred  when  an  Angle-of-Attack  value,  which  was  below  the 
Ada  type  specification  lower  limit,  was  passed  from  the  C++  to  the  Ada.  Systems  Engineering  analysts 
decided  that  the  value  could  not  be  experienced  in  a  closed  loop  flight  environment  and  the  problem  was 
dispositioned  as  unrealistic.  Systems  engineering  considered  incorporation  of  logic  on  the  C++  side  to  limit 
the  value  passed  to  the  Ada  side,  but  decided  it  would  offer  no  benefit  in  terms  of  system  robustness  and 
safety. 

4.3.5  External  Data  Access 

The  only  external  data  access  involved  in  the  modifications  required  for  the  demonstration  was  the  display 
and  voice  warning  output.  Normally,  in  a  complete  upgraded  hardware  suite,  the  OWS  warnings  would  be 
provided  by  a  set  of  tones,  and  the  wrapper  would  have  been  constructed  to  provide  the  requisite  data 
automatically.  However,  because  the  existing  hardware  did  not  support  this  function,  an  alternative  method 
using  the  "low  altitude  -  pull  up"  voice  warning  caution  was  used.  The  voice  warning  output  was  hand-coded 
in  C++  and  integrated  into  the  wrapper  using  WrapidH.  The  voice  warning  was  needed  to  provide  a  good 
distinct  immediate  feedback  to  the  crew  that  the  OWS  logic  was  working  satisfactorily.  The  display  drivers 
were  developed  using  the  VAPS  GUI  Tool-set  and  hand  integrated  into  the  OFP. 

4.4  Development  Environment 

The  ideal  development  environment  for  the  OWS  Demonstration  would  accommodate  both  C++  and  Ada 
for  both  Desktop  (PC)  and  target  (PowerPC).  Unfortunately,  at  the  time  of  initiation  of  the  OWS 
Demonstration  effort,  no  such  integrated  environment  existed.  Green  Hill  Ada  MULTI  provided  the  requisite 
capabilities  for  the  PowerPC  target  but  not  the  Desktop  PC.  For  the  Desktop,  Green  Hills  MULTI  was 
capable  of  developing  the  Ada  object  code  only,  i.e.  it  had  no  Desktop  C++  capability.  The  development 
environment  in  use  for  the  COFP  was  Microsoft  Visual  C++  Developers  Studio.  It  offered  capabilities  to 
develop  and  debug  Desktop  PC  C++  applications  and  to  integrate  C++  and  Ada  object  code  into  a  desktop 
executable.  The  Microsoft  tool  had  the  added  advantage  that  it  was  widely  available  in  the  Boeing  Bold 
Stroke  organization  and  numerous  developers  were  familiar  with  it.  It  did  not  offer  an  integrated  de¬ 
bugging  environment  for  the  integrated  object  code.  The  decision  boiled  down  to  using  the  Microsoft 
environment  for  the  Desktop  effort  or  using  the  Green  Hills  environment  and  going  directly  to  the  target 
machine.  There  were  numerous  risks  associated  with  this  second  approach: 

•  The  Green  Hills  product  was  less  proven  than  the  Microsoft  product 

•  Few  developers  were  familiar  with  the  Green  Hills  product 

•  Target  machine  availability  would  be  a  serious  bottleneck 

•  Plans  called  for  using  the  Desktop  Test  Environment  (DTE)  for  initial  debugging  of  the  integrated 
product  -  DTE  integrated  with  the  development  environment  was  not  available  for  the  target 
processor. 

Of  necessity,  the  decision  was  made  to  use  the  Microsoft  tools  for  completion  of  the  Desktop  effort  and 
transition  to  the  Green  Hills  tools  for  the  target  machine.  Although  no  other  viable  path  existed,  the  lack  of 
an  integrated  de-bugging  environment  proved  to  be  extremely  time-consuming.  Since  the  bulk  of  the  OWS 
problem  is  the  importing  of  the  C++  data  into  the  Ada  threads,  debugging  is  almost  completely  done  on  the 
Ada  side.  Because  there  was  no  integrated  environment,  debugging  on  the  Ada  side  required 
incorporation  of  diagnostic  code,  recompilation  and  extensive  data  analysis.  Needless  to  say,  this  was  a 
time  consuming  process,  but  was  unavoidable.  In  future  efforts  every  effort  should  be  made  to  ensure  that 
an  integrated  environment  is  available  for  each  phase  of  the  development. 
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4.5  Wrapper  Implementation 

The  OWS  Wrapper  was  developed  using  the  lULS  Wrapper  Toolset  (WrapidH)  which  was  created  for  the 
lULS  Program  using  the  Honeywell  Domain  Modeling  Environment  (DoME),  as  depicted  in  the  following 
figure. 


The  software  architecture  implemented  for  the  demonstration  is  shown  in  the  following  figure.  The  key 
element  of  this  architecture  is  the  lULS  Wrapper,  which  was  developed  using  WrapidH.  The  lULS 
Wrapper  contains  407  Source  Lines  of  Code  (SLOG)  of  automatically  generated  C++  code  and  482  SLOG 
of  automatically  generated  Ada95  code.  The  Rehosted  OWS  software,  which  was  wrapped,  contains 
7200  SLOG  of  Ada83. 


Figure  19.  Upgraded  Software  Architecture 
4.5.1  Build/Modify  Wrapper  Model 

The  data  and  processing  components  were  incorporated  into  a  wrapper  software  model,  “OWS_Wrapper” 
using  WrapidH.  The  following  figures  show  a  portion  of  the  wrapper  model  at  various  levels.  The  intent  in 
showing  these  particular  figures  is  to  illustrate  a  sample  string  of  data  and  control  flow  through  the  model. 
The  following  figure  shows  the  top  level  of  the  model  -  a  depiction  of  the  modeled  software  components  in 
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the  WrapidH/DOME  user  interface  on  a  PC/NT  Workstation. 


Figure  20.  Top  Levei  Wrapper  Modei 

The  name  of  the  modei  is  BIG-OWS-WRAPPER.DOM  as  is  indicated  in  the  window  iabei.  The  wrapper 
has  an  initiaiization  process  at  the  top  and  three  processes  to  perform  on  a  reguiar  basis  that  enciose  the 
iegacy  processes.  The  other  processes  depicted  in  this  figure  are  run  on  an  as-needed  basis  inciuding 
data  access  methods  used  by  the  Host  to  “get”  the  OWS  outputs  for  dispiay  and  vaiidity  fiags. 

The  two  processes  that  wiii  be  described  in  more  detaii  are  “PERFORM_OWS_20HZ_Wrapper”  and 
“GetMOST  RECENT  DISPLAY  NZ”.  These  processes  are  scheduied  by  the  Host  infrastructure  at  20  Hz. 
The  “PERFORM_OWS_20HZ_Wrapper”  process  converts  data  from  the  Host  environment  to  the  Legacy 
OWS/Ada  environment  and  then  caiis  processes  to  be  executed  in  the  Ada  environment.  The  second 
process  “GetMOST  RECENT  DISPLAY  NZ”  primariiy  gets  the  data  that  has  been  generated  in  the  Ada 
environment  and  converts  it  for  the  Host  environment  so  that  it  can  be  used  to  dispiay  normai  acceieration 
(“G’s”)  on  the  HUD. 

The  wrapper  designer  uses  the  DOMEA/VrapidH  tooi  to  navigate  through  the  modei  by  point-and-ciick  on 
the  desired  components.  Components  with  a  biock  in  the  top-right  corner  have  a  iower-ievei  modei. 
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The  next  level  of  the  model  for  the  process  “PERFORM_OWS_20HZ_Wrapper”  Is  shown  In  the  following 
figure. 


Figure  21 .  Perform  OWS  20HZ  Wrapper  (Part  1 ) 


The  aircraft  state  data  that  Is  required  by  the  OWS  Input  Ada  PIMs  has  been  Identified,  and  their 
equivalent  “C  PIM”  structures  are  shown  to  the  right,  such  as  “ADC_C_PIM”.  Each  required  parameter 
(such  as  Mach  Number)  Is  shown  as  an  Input.  The  equivalent  Host  parameters  (and  their  access  methods) 
have  been  Identified  In  a  Host  structure  modeled/labeled  A5ADP  (Air  Data  Process)  on  the  left.  The  data 
Is  passed  through  Intermediate  components  (In  the  center)  that  convert  the  data  to  a  different  type,  convert 
the  units,  or  simply  assign  It  (and  Its  validity)  to  the  Intermediate  storage  locations  In  the  *_C_PIMs. 
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The  lower  part  of  the  “PERFORM_OWS_20HZ_Wrapper”  model  Is  depicted  In  the  following  figure.  It 
shows  this  process  activating  another  process  called  “OWS_20HZ_Transfer_TO_ADA”  In  the 
“OWS_20HZ_PIM_TRANSFER  package  after  the  required  data  has  been  loaded  In  the  Input  *_C_PIMs. 


Figure  21 .  Perform  OWS  20HZ  Wrapper  (Part  1 ) 
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Figure  22.  Perform  OWS  20FIZ  Wrapper  (Part  2) 

The  following  figure  shows  part  of  the  next  level  “OWS_20FIZ_Transfer_TO_ADA”  which  basically  converts 
the  data  in  the  *_C_PIMs  to  the  *_ADA_PIMs.  Once  all  of  the  PIMs  have  been  converted,  the  Legacy  Ada 
code  to  PERFORM_OWS_20FIZ  can  be  activated  as  shown  in  the  ‘D_OWS_20_FIZ”  package  near  the 
bottom. 
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Figure  23.  OWS  Transfer  to  Ada 

Once  the  Legacy  OWS  has  been  executed  the  results  are  copied  to  the  output  *_C_PIMs  by  executing  the 
process  “OWS_20_FIZ_Copy_Outputs”,  shown  in  the  following  figure  at  the  lowest  level  of  the  model. 
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Figure  24.  OWS  20  FIz  Copy  Outputs 

Note  in  the  foilowing  figure  that  the  variabie  “MOST_RECENT_DISPLAY_NZ”  is  one  of  the  data  fields  to 
be  converted.  This  is  the  variable  needed  by  the  top-level  process  “GetMOST  RECENT  DISPLAY  NZ”  in 
the  following  figure. 
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Figure  25.  Display  NZ 


The  properties  for  each  model  component  such  as  the  D_OWS_20_FIZ_C_PIM  package  are 
entered/shown  in  a  property  inspection  window  depicted  in  the  following  figure.  In  this  case,  the  package 
code  does  not  exist  (either  imported  or  on  the  shelf),  and  will  be  generated  in  Ada  and  C++.  The 
package’s  description,  design  rationale,  links/cross-references,  appearance,  and  other  characteristics  are 
entered  through  the  window. 
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Figure  26.  Component  Properties 

4.5.2  Build/Modify  Wrapper  Components 

Every  component  type  shown  in  the  modei  has  associated  source  code.  These  components  can  be  buiit 
within  the  DOME/WrapidFI  tooi  by  using  the  buiit-in  graphicai  editing  toois  and  property  specifications,  or 
their  source  code  can  be  imported  via  the  “Toois”  menu  option.  An  Ada  parser  was  used  to  extract 
portions  of  the  iegacy  VCC  OFP  containing  OWS-reievant  source  code  into  a  representation  that  couid  be 
ioaded  onto  DOME  and  processed  by  WrapidFI. 

The  data  and  controi  transforms  were  coded  by  hand,  or  auto-coded  by  the  WrapidFI  tooi  from  their  type 
and  graphicai  specifications.  The  stubs  were  hand-coded.  Future  editions  of  the  WrapidH  tooi  wiii  be  abie 
to  modei  and  auto-code  more  of  these  components.  Aii  software  components  that  were  deveioped  for  the 
case  study  were  added  to  the  Wrapper  Library  and  are  avaiiabie  to  future  users  of  the  tooiset  via  the 
Sheif. 

4.5.3  Generate  Wrapper  Code 

The  foiiowing  figure  contains  the  C-n-  source  code  generated  by  WrapidH  for  the  “OWS_20Hz_C_PIM”. 
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File  generated  by  WrapidFI,  version  1 .3 

#ifndef  D_OWS_20_HZ_C_PIM_h 
#define  D_OWS_20_HZ_C_PIM_h  1 
include  "INTERFACES.C.h" 

#include  "D_OWS_TYPES.h'' 

typedef  struct  { 

double  MAX_POSITIVE_MAGNITUDE_G; 
double  MAX_NEGATIVE_MAGNITUDE_G; 
double  MOST_RECENT_DISPLAY_NZ; 
double  MOST_RECENT_DISPLAY_RATIO; 

RECALL_DATA_COMPONENT_TYPE  MOST_RECENT_DISPLAYJNDEX; 
}  D_OWS_20_HZ_C_PIM_TYPE; 
extern  "C"  { 

extern  D_OWS_20_HZ_C_PIM_TYPE  OWS_20_HZ_C_PIM; 

); 

#endlf 


Figure  27.  Component  Code 


The  following  figure  depicts  the  WrapidFI  code  generating  process  for  the  updated  OFF  that  combines 
legacy,  wrapper  and  new  Host  components.  The  key  ingredient  in  the  process  is  the  Wrapper  Design 
model  that  is  an  output  of  the  Wrapper  Design  Step.  For  the  OWS  study  several  iterations  of  this  process 
were  necessary  since  this  was  one  of  the  first  uses  of  WrapidH  on  a  large  software  system.  Tool  features 
and  refinements  were  added  during  each  wrapper  design  iteration. 


r  TTT 


Legacy  &  Wrapper 


Figure  28.  Generate  Wrapper  Code 
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A  sample  of  the  C++  code  listing  (file  OWS_Wrapper.cpp)  that  is  called  from  the  Host  interface  is  shown  in 
Appendix  C.  This  code  contains  the  functions  ‘'GetMOST_RECENT_DISPLAY_  NZ”  and 
“PERFORM_OWS_20HZ_Wrapper”.  Also  note  that  the  function  “OWS_20HZ_PIM_TRANSFER_ 
OWS_20HZ_Transfer_To_Ada”  is  called  from  within  the  function  “PERFORM_OWS_20HZ_Wrapper”. 

The  Ada95  code  listing  generated  by  WrapidH,  OWS_20Hz_PIM_TRANSFER.ada,  is  contained  in 
Appendix  D.  It  includes  the  procedures  OWS_20HZ_Transfer_To_Ada,  the  PRAGMA  to  export  Ada  to  C, 
and  the  procedure  OWS_20_HZ_Copy_Outputs. 

4.5.4  Link  With  OFP 

The  legacy  OWS  code  and  new  Wrapper  code  were  compiled  and  linked  with  the  Host  OFP  code  in  the 
Boeing  F-15  Desktop  Test  Environment  (DTE)  on  a  PC/NT  Workstation  for  wrapper  evaluation  and  initial 
software  integration  and  testing.  Microsoft  Visual  C++  and  Green  Hills  Ada  MULTI  for  PentiumA/Vindows 
were  employed.  An  ensemble  of  test  cases  was  extracted  from  the  original  set  of  OWS  verification 
procedures.  Test  cases  were  chosen  to  exercise  all  elements  of  the  OWS  Wrapper  and  covered  all 
demonstration  test  points.  A  significant  advantage  of  reclaiming  legacy  code  is  that  code  integrity  is 
maintained.  It  is  not  necessary  to  verify  every  test  condition  considered  in  the  original  verification  plan 
because  the  legacy  code  performs  identically  with  the  original  implementation.  This  was  borne  out  during 
the  OWS  Wrapper  verification  process.  As  expected  many  problems  were  encountered.  In  all  cases  they 
were  traced  to  elements  of  the  wrapper  -  generally  things  missing  in  COFP.  No  problems  were 
encountered  in  the  areas  controlled  by  the  legacy  code. 

4.5.5  Evaluate  Wrapped  System 

The  goal/purpose  of  this  phase  of  lULS  was  to  produce  wrapper  components  and  a  functional  OFP  that 
compiled  and  ran  on  the  F-15  DTE  to  evaluate  the  quality,  structure  and  performance  of  the  WrapidH- 
generated  software.  The  WrapidH  tool  was  enhanced  and  refined  based  on  the  results  of  the  initial 
passes  through  the  Wrapper  Build,  Code  Generation  and  Link  with  the  OFP. 

When  the  system  was  ready  for  system  test  and  evaluation  it  was  recompiled  and  linked  using  Green  Hills 
Ada  MULTI  for  PowerPC/VxWorks  and  downloaded  to  the  ADCP’s  General  Purpose  Processor  (GPP) 
Module  in  an  F-15  Software  Test  Facility  (STF)  environment. 

The  relative  sizes  of  the  components  (in  source  lines  of  code)  for  the  final  demonstration  and  flight  test 
OFP  were: 


Component 

Software  Lines  of  Codes 
(Not  Comment/Blank) 

Total  Source  Lines 

Total  OFP  (C++  and  Ada) 

119363 

534054 

OWS  Application  (Ada  Including  PIMs) 

7195 

23738 

Ada  Wrapper 

482 

880 

C++  Wrapper 

408 

811 

Table  8.  Software  Component  Size 

The  average  execution  times  on  the  ADCP  GPP  processor  card  for  a  20  Hz  frame  (50  milliseconds 
available)  that  includes  all  20  Hz  and  10  Hz  processing  are  shown  in  the  following  table.  It  is  noteworthy 
that  the  20  Hz  wrapper  uses  7.2  msec  /  sec  and  the  10  Hz  wrapper  uses  1 .6  msec/sec.  This  represents  a 
total  of  8.8  msec/sec  for  wrapper  execution  which  is  less  that  1  percent  of  the  available  throughput. 


Component 

20  Hz 
Tasks  (ms) 

10  Hz 

Tasks  (ms) 

All  Tasks  / 
Frame  (ms) 

Complete  OFP  (C++  and  Ada) 

22.49 

6.06 

34.25 

OWS  Application  (Ada  Including  PIMs) 

0.58 

0.78 

1.36 

Wrapper  Application  (C++  and  Ada) 

0.36 

0.16 

0.52 

Table  9.  Software  Throughput  Usage 
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4.6  Test  Wrapped  System 

Three  levels  of  testing  were  performed  to  support  the  laboratory  demonstrations  and  for  flight 
qualification: 

1.  Software  testing  of  the  OFP  was  performed  In  the  DTE  Workstation  and  on  the  ADCP  target  In  the  F- 
15  Project’s  Software  Test  Facility  with  functional  test  scripts.  An  Important  aspect  of  this  testing  was 
to  verify  the  Integrity  of  the  processing  using  software  Instrumentation  such  as  Wind  River  Tornado™. 
These  tools  allow  the  designer/tester  to  visualize  the  detailed  execution  of  each  task  and  processing 
frame  under  normal  operation,  Initialization,  and  mode  transitions  (Including  degradation). 

2.  The  ADCP  OFP  was  functionally  tested  on  an  Integrated  F-15  avionics  system  “hot  bench”.  In  an  F-15 
Flight  Simulator  by  the  F-15  Project  Pilot  and  system  test  personnel,  and  In  an  F-15E  test  aircraft  on 
the  ground  using  standard  F-15  Production  Test  Procedures. 

3.  Following  an  F-15  Flight  Certification  Board  review,  a  flight  test  of  the  upgraded  OWS  functionality 
(and  the  “retention”  of  baseline  Host  functionality)  took  place  on  1  December  1999  In  F-15E1.  The 
demonstration  flight  plan  called  for  execution  of  six,  test  points.  These  corresponded  to  combinations 
of  three  different  weapon  loads  with  two  different  fuel  configurations.  The  test  points  were  selected  to 
exercise  the  85%,  92%  and  100%  OWS  triggers.  The  Pilot,  Weapon  Systems  Officer  and  Flight  Test 
Engineer  reported  successful  test  results.  In  order  to  test  the  OWS  In-fllght  without  actually  stressing 
the  airframe  under  excessive  G’s,  the  weapon  and  fuel  load  Inputs  to  the  OWS  processing  were 
manually  set  by  the  aircrew  through  the  Up  Front  Control  Keyboard  to  establish  the  test  points  for  a 
fully  loaded  flight  scenario.  Using  these  sets  of  calibrated  weight  Input,  the  OWS  computed  and 
reported  all  warnings  and  overload  factors  accurately  on  the  cockpit  displays  as  the  aircraft 
maneuvered. 

4.7  F-15  Demonstration  Summary 

The  F-15  demonstration  thoroughly  validated  the  lULS  rehost  process  and  toolset.  Operationally  the 
demonstration  received  enthusiastic  endorsement  from  the  flight  crew  who  referred  to  It  as  a  “Home  Run” 
In  the  post  flight  debrief.  The  In-fllght  performance  was  100%  In  agreement  with  the  a  priori  estimates 
matching  all  six  test  points,  exactly.  The  WrapIdH  tool  proved  to  be  extremely  valuable  In  developing  the 
wrapper  design  and  the  automated  code  generator  worked  as  expected  In  both  the  Ada  and  C-i-i-  domains. 
As  predicted  considerable  domain  expertise  was  required  to  develop  the  wrapper.  However,  the  bulk  of 
this  work  was  performed  by  lULS  engineers  who  Initially  had  no  familiarity  with  the  heritage  code.  These 
engineers  were  able  to  readily  understand  the  legacy  Ada  and  COFP  C-i-i-  to  the  extent  required  to  support 
wrapper  design  and  system  de-bug.  Wrapper  testing  confirmed  the  prediction  that  wrapped  code  Integrity 
would  be  Intact  -  no  problems  were  detected  In  which  wrapped  code  operation  was  an  Issue. 
Measurement  of  wrapped  system  performance  confirmed  that  the  automatically  generated  code  was 
efficient,  requiring  less  than  1  percent  of  the  available  system  throughput.  This  also  confirmed  the  Task  1 
system  modeling  which  had  predicted  system  throughput  was  more  than  adequate  for  the  demonstration 
requirements. 

Probably  the  only  negative  of  the  demonstration  resulted  from  changes  In  the  F-15  customer’s  program 
plan,  which  occurred  late  In  the  demonstration  effort.  The  OWS  demonstration  was  designed  to  aid  In  the 
transition  from  an  Ada  OFP  to  a  C-i-i-  OFP.  This  was  In  accordance  with  the  customer  roadmap  at  the 
time  the  demonstration  was  definitized.  The  customer  had  planned  to  transition  the  wrapped  OWS 
software  as  tested  which  would  have  decreased  the  source  lines  of  code  to  be  developed  by 
approximately  7000.  In  addition,  the  customer  was  poised  to  use  the  wrapper  tool  In  lieu  of  re-engineering 
several  other  OFP  functions  to  00  C-i-i-  pending  success  of  the  lULS  demonstration.  These  Included  the 
GCWS  (ground  collision  warning  system)  and  ZAP  (launch  zones)  and  totaled  over  25,000  lines  of 
additional  code  that  would  have  been  wrapped  vice  re-engIneered. 

Because  of  funding  priorities,  the  F-15  SPO  subsequently  decided  to  continue  with  the  Ada  OFP  as  the 
baseline  rather  than  transitioning  to  the  C-i-i-  baseline.  Because  of  this  decision  the  wrapped  OWS 
software  will  not  transition  to  an  operational  capability.  However,  It  will  continue  to  support  technology 
demonstrations  and  Is  the  baseline  for  the  Weapon  System  Open  Architecture  (WSOA)  demonstration, 
which  Is  In  development. 

The  lULS  F-15  technology  demonstration  was  an  unmitigated  success  and  received  a  letter  of 
endorsement  from  the  F-15  program  along  with  press  coverage  In  Aviation  Week  magazine  (Aerobytes,  21 
Feb  2000)  and  other  trade  journals.  It  demonstrated  the  utility  of  the  automatic  wrapper  generation 
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process.  Whilst  the  seminal  F-15  example  selected  for  our  demo  emphasized  wrapping  legacy  Ada 
components  into  a  C++  OFP,  lULS  technology  is  also  directly  applicable  to  the  reverse  case  -  wrapping 
C++  components  into  an  Ada  OFP.  This  specific  technique  may  be  directly  applicable  in  the  WSOA 
demonstration  as  we  work  to  transition  C++  image  processing  and  display  software  to  the  Ada  Suite  5 
OFP. 
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5  C-1 7  lULS  Demonstration 

The  requirement  for  lULS  Task  2  was  a  realistic  demonstration  of  the  application  of  the  lULS  tools  and 
processes  to  a  realistic  legacy  avionics  domain  -  the  goal  was  to  execute  two  demonstrations.  An  F-15 
demonstration  was  the  first  priority  and  the  initial  focus  of  Task  2.  The  OWS  Demonstration,  described 
above,  was  chosen  and  the  demonstration  plan  was  definitized.  Because  the  flight  demonstration  assets 
were  made  available  without  charge  to  the  lULS  program,  sufficient  funding  remained  to  execute  a  second 
demonstration.  Since  the  F-15  OWS  demonstration  confirmed  the  Rehost  approach,  and  to  a  limited 
extent  the  Hybrid  approach,  the  goal  was  to  find  an  application  in  which  emulation  was  appropriate.  The 
C-1 7  program,  which  had  outgrown  the  capabilities  of  its  baseline  1750A  Avionics  Architecture  was 
identified  as  the  best  candidate  for  transitioning  lULS  emulation  techniques. 

5.1  Emulator  Framework 

An  upgrade  technique  that  uses  an  ISA  emulator  employs  a  subset  of  the  wrapper  components.  The 
emulation  architecture  is  illustrated  in  the  following  figure.  The  ISA  emulator  (here  shown  as  a  software 
task)  implements  the  legacy  ISA  state  machine.  The  emulator  program  interfaces  with  the  system 
thorough  the  wrapper  services.  The  Target  Memory  Space  is  a  binary  load  image  of  the  legacy  OFF.  The 
basic  features  and  elements  of  an  emulator  wrapper  are  the  following: 

•  Wrapper  control  -  the  wrapper  process  executes  as  a  task  of  the  host  Executive  or  RTOS 

•  Emulator  initialization  -  loads  and  initiates  the  OFP  image. 

•  Process  and  data  synchronization 

•  Interrupts  and  Synchronization 

•  Clock  services 

•  Legacy  “system”  reset 

•  Shared  data  access 

•  “Peek”  into  legacy  memory  space 

•  “Poke”  or  change  legacy  memory  space. 

•  External  data  access 

•  Input  handler 

•  Output  handler 

•  Data  reformatting 

•  Legacy  machine  state  vector 

•  Virtual  switches  and  discrete  signals. 

•  Restart  cycling 

•  Checkpoint  and  test  instrumentation 


OFP 

Code 

Space 


Emulator 

Program 


Wrapper  Layers 


Figure  29.  Emulator  Architecture 


5.1.1  Emulator  Trade  Study 

Emulation  became  a  useful  technology  in  the  late  1960’s.  Thus,  the  market  is  mature  and  product  offerings 
are  reasonably  well  understood.  The  following  trade  study  was  performed  in  the  lULS  Task  1  period.  The 
study  represents  a  wide  cross  section  of  the  available  commercially  available  products.  Products  were 
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selected  for  the  availability  of  a  1750A  ISA  product  or  a  product  easily  modifiable  to  the  1750A  ISA.  The 
vendors  and  products  considered  in  the  trade  study  were: 


Vendor 

Product 

CCT  -  Anaheim,  CA 

Firmware  processor  emulator  of  the  AP-101  A-6  mission  processor 

Visicom  -  San  Diego,  CA 

Emulators  of  UYK-20,  UYK-7,  UYK-43  processors.  Tightly  coded 
machine  language  emulator  on  a  commercial  processor,  bridge  for 
NTDS  I/O  card  set 

CPU  Technology  - 
San  Diego,  CA 

Hardware  emulator  of  1750  ISA.  Product  incorporates  MIPS  R3000 
core  as  additional  ISA  choice.  Chip  emphasis  on  throughput. 

Northrop-Grumman  -  Pico 
Rivera,  CA 

Software  emulator  of  B-2  1750  variant  (approx.  1  MIP).  Demonstrated 
on  COTS  processor  board,  COTS  I/O  card  set 

TRW  -  Dayton,  OH 

Software  emulator  of  1750  ISA.  COTS  processor  host  (PowerPC), 
technically  similar  to  Northrop-Grumman 

Table  10.  Emulator  Candidates 

The  trade  issues  that  were  considered  in  the  study  emphasized  the  flexibility  and  migration  capability  of  the 
product.  These  evaluation  factors  are  subjective  parameters.  The  selection  of  best  and  marginal 
examples  for  each  factor  was  based  on  information  provided  by  the  vendors.  In  some  cases  there  was 
little  current  information  provided  by  the  vendor.  In  these  cases  GDIS  relied  on  recent  experience  with  the 
product. 

The  evaluation  criteria  selected  for  the  trade  study  were  as  followed: 

1 .  Cost  to  correct  latent  errors. 

2.  Intersection  with  mainstream 

•  Reacting  to  change  in  the  mainstream. 

3.  Migration  path  options 

•  Can  the  product  be  used  as  a  Rehost  platform? 

4.  Cost  to  change  host  platform 

•  Any  custom  design  required? 

5.  Emulation  fidelity  index 

•  Ability  to  avoid  OFP  modification. 

Item  1  refers  to  the  cost  to  correct  any  error  in  the  legacy  state  machine  (ISA  emulator).  A  software  or 
firmware  emulator  implementation  is  less  costly  to  modify  than  a  hardware  implementation.  Items  2  and  3 
recognize  that  the  legacy  OFP  may  be  eventually  be  migrated  to  a  COTS  processor  (similar  to  the  Rehost 
option)  at  some  point  in  the  future.  An  emulation  option  that  is  hosted  on  a  mainstream  COTS  processor  in 
a  “popular”  language  is  preferred  over  a  design  that  includes  a  high  level  of  optimization.  In  addition,  a 
portable  emulation  implementation  (in  a  language  such  as  C++)  is  superior  to  other  choices.  Item  4  favors 
the  use  of  off  the  shelf  microprocessors  as  opposed  to  custom  devices.  That  is,  the  COTS  processor  will 
change  over  time  (typically  in  18  to  24  month  cycles)  and  if  any  custom  design  is  required  (gate  array, 

EGA,  etc.)  to  implement  the  emulation  engine  then  that  design  is  less  desirable.  Item  5  recognizes  that 
some  technology  may  be  superior  in  addressing  the  “last”  nanosecond  of  fidelity.  This  factor  is  important, 
but  it  is  also  a  trade  issue.  The  trade-off  factor  is  the  cost  of  potentially  modifying  a  small  portion  of  the 
legacy  OFP  relative  to  all  other  factors. 

A  summary  of  the  trade  study  results  are  presented  below: 
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Criteria 

Preferred  Product 

Product  Barriers 

1 .  Cost  to  modify 
product 

Software  emulator:  TRW,  Northrop- 
Grumman,  VIsIcom 

Firmware  emulator:  CCT 

Hardware  emulator:  CPU  Tech 

2.  Intersection 
with  mainstream 

C  software  on  COTS:  TRW,  Northrop- 
Grumman 

Custom  Implementation:  CCT,  CPU 
Tech 

3.  Migration  path 

COTS  board  set:  TRW,  North rop- 
Grumman,  VIsIcom 

No  commercial  path:  CCT,  CPU  Tech 

4.  Cost  to  change 
host 

No  known  custom  designs:  TRW, 
Northrop-Grumman 

Custom  device:  CPU  Tech 

5.  Emulation 
fidelity 

Hardware  Implementation:  CPU  tech, 
CCT 

Software  on  COTS:  TRW,  Northrop- 
Grumman,  VIsIcom 

Table  1 1 .  Emulator  Trade  Study 
5.1 .2  Emulator  Strawman  Architecture 

A  strawman  architecture  for  an  emulator  based  upgrade  system  Is  shown  below.  This  hardware 
configuration  reflects  the  COTS  class  of  embedded  processing  systems  at  completion  of  lULS  Task  1. 
The  primary  elements  are  a  single  board  computer  module  (or  modules),  one  or  more  primarily  I/O 
modules  (possibly  Incorporating  a  processor  and  kernel  OS),  and  a  backplane  bus  (VME64  In  this 
example).  The  architecture  allows  for  the  distribution  of  wrapper  services  across  the  various  modules. 
The  backplane  bus  and  distributed  architecture  are  critical  factors  In  the  process  of  designing  a  real-time, 
embedded  emulation  engine  Implemented  upgrade  for  an  application  such  as  the  C-17  ARM  or  CCU. 
These  Items  were  addressed  In  the  modeling  and  simulation  phase  on  Task  1. 
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Figure  30.  Emulator  Strawman  Architecture 
5.1.3  Emulation  Environment 

Wrapper  services  for  an  emulation  environment  are  primarily  concerned  with  Interfacing  a  software  task 
(the  ISA  emulator  program)  with  a  hardware  configuration  and  the  RTOS  being  used  (e.g.,  VxWorks  on  a 
PowerPC  COTS  board).  Additional  services  are  provided  within  the  wrapper  environment  to  accomplish 
the  following: 

1.  Provide  an  Interface  to  the  operator/integrator.  The  wrapper  services  provide  a  “monitor”  type 
Interface  and  debugging  support.  The  Integration  of  the  legacy  OFP  with  the  emulator  requires  a 
capability  to  execute  the  legacy  OFP  In  a  controlled  environment. 

2.  Provide  Instrumentation  capability.  Validation  of  the  emulator  environment  will  require  the  ability  to 
collect  operational  data  In  a  bench  test  mode. 
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3.  Incorporate  an  escape  mechanism.  The  emulator  and  the  wrapper  services  should  include  a  method 
for  escape  to  the  native  mode  of  the  emulation  engine  (e.g.  PowerPC,  VxWorks,  etc.).  The 
requirement  is  to  be  able  to  escape  and  return  in  a  controlled  way. 

5.1 .4  Emulation  Tool  Selection 

Early  in  Task  2  (March  -  1998)  a  briefing  was  given  to  the  lULS  Customer  and  the  C-17  SPO.  At  the  time 
of  the  briefing  lULS  funding  had  been  identified  to  support  a  Cl 7  emulation  demonstration.  An  APM 
demonstration  was  recommended  and  the  combined  customers  were  asked  to  review  and  comment  on  the 
recommended  approach.  At  this  time  a  tentative  decision  to  acquire  the  TRW  1750A  emulator  technology 
for  the  APM  upgrade,  pending  resolution  of  certain  programmatic  and  technological  issues,  was  briefed. 
The  selection  of  the  TRW  emulator  confirmed  the  Task  1  Emulator  Trade  Study  which  indicated  that  the 
TRW  tool  was  a  strong  candidate  for  the  lULS  problem  domain.  Programmatic  issues  to  be  finalized 
included: 

•  Transitionable  technology 

•  Availability  for  open  evaluation 

•  Visibility  into  technology 

•  Terms  of  license  agreement. 

Technological  issues  included: 

•  Interface  openness 

•  Availability  of  emulated  application  to  software  access 

•  I/O  emulation  /  access  to  devices 

•  Demonstration  approach. 

These  issues  were  analyzed  in  parallel  with  the  customer  evaluation  of  the  recommended  APM 
demonstration,  described  below.  In  all  cases,  the  programmatic  and  technical  issues  were  resolved  in 
favor  of  selecting  the  TRW  tools.  As  described  below,  the  customers  subsequently  decided  on  a  CCU 
emulation  as  being  in  the  best  interest  of  both  lULS  and  the  C-17.  By  the  time  of  the  redirection  of  the 
demonstration  effort  had  been  promulgated  into  a  program  plan,  the  decision  to  use  the  TRW  emulator 
was  made.  An  overview  of  TRW’s  RePLACE  Emulator  is  shown  in  the  following  figure. 
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Figure  31 .  Overview  of  TRW’s  RePLACE  Emulator 
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5.2  C-1 7  Avionics 

The  C-1 7  produced  by  Boeing’s  Military  Transport  Aircraft  (MTA)  division  contained  a  federated  avionics 
system  that  had  much  in  common  with  combat  aircraft  including  its  software  domains.  It  contained  two 
1553  busses  controlled  by  redundant  mission  processors  -  three  Missions  Computers,  which  at  that  time 
were  to  be  replaced  by  two  Core  Integrated  Processors  (CIPs).  The  other  major  system  busses  were  the 
Warning  and  Cautions  bus  and  the  four  engine  control  busses.  The  pilot  and  co-pilot  had  HUDs  and  multi¬ 
purpose  displays  whose  formats  were  generally  configured  by  the  mission  processors;  there  was  no 
dedicated  display  processor. 

The  table  below  lists  the  C-1 7  avionics  subsystems  that  were  subject  to  frequent  updates  and  were 
potential  candidates  for  the  demonstration. 


Subsystem 

Major  Functions 

Processor 

OFP 

Language/Size 

(Words) 

Vendor 

H/W  /  S/W 

Aircraft/Propulsion  Data 
Management  Computer 
(APM) 

Collects  and  processes  data, 
performs  signal  conditioning,  and 
packs/unpacks  data  for  the  Avionics, 
Propulsion  and  Warning  and  Caution 
Busses 

1750A 

JOVIAL /AL 
108K 

Flamilton- 
Standard  / 

MTA  from  HS 

Central  Aural  Warning 
Computer  System  (CAWS) 

Generates  tones  and  voice 
messages  for  the  aircrew  and 
loadmaster 

MC6800 

C 

MDA  (Monrovia) 

/  MDA-M 

Communication  Control 
Unit  (CCU) 

Distributes  audio  communications 
among  the  radios  and  crew  stations 

1750 

Core  Integrated  Processor 
(CIP) 

Performs  mission  processing 
including  navigation,  guidance,  flight 
planning,  performance  prediction, 
aircrew  display  and  control,  system 
management,  communications 
management,  and  database 
management 

R4400 

Ada83  /  C 

LM / MDA 

Flight  Control  Computer 
(FCC) 

Four  channel  flight  control  processing 
to  drive  the  primary  control  surfaces 
and  engines. 

1750 

JOVIAL /AL 

LM/LM 

Mission  Computer/ 
Communications  Keyboard 
(MCK) 

Provides  alphanumeric  data  entry  and 
pushbuttons  to  control  Mission 
Communications  Display  (MCD) 
pages  and  COMM/NAV  controls 

MC68000 

AL 

Delco  /  Delco 

Multi-function  Display 
(MFD) 

Two  color  6x6  cockpit  displays  for 
mission  and  aircraft  performance 
information 

1750 

JOVIAL /AL 

Floneywell  / 
Floneywell 

Warning  and  Caution 
Computer  (WAC) 

Collects  caution,  warning  and  failure 
information  form  airframe  systems  and 
formats  it  for  C&D 

1750 

JOVIAL 

Litton  /  Litton 

Table  12.  C-1 7  Subsystems 

The  APM,  CAWS,  and  WAC  were  internal  signal  processing  subsystems  containing  relatively  non-volatile 
software.  However,  their  processing  hardware  was  becoming  obsolete,  and  software  maintenance  costs 
by  subcontractors  were  increasing  due  to  relatively  unique  software,  languages  and  software  engineering 
environments  (SEEs).  MTA  was  in  the  process  of  bringing  their  software  in-house.  There  were  also 
proposals  to  bring  their  functionality  into  the  CIP  that  had  spare  card  slots.  However,  this  architectural 
change  would  require  extensive  rewiring  of  the  aircraft,  which  was  not  practical,  until  it  was  forced  by  other 
major  functional  upgrades.  An  APM  emulation  was  the  original  recommendation  for  an  lULS  Task2  C-1 7 
demonstration. 

The  MCK  and  MFD  were  typical  control/display  upgrade  candidates.  The  display  head  technology  (CRTs 
and  low  resolution  LCDs)  was  growing  obsolete,  the  units  had  limited  functionality  and/or  resources  and 
software  maintenance  was  expensive.  C&D  architectural  changes,  which  move  to  a  centralized  display 
processor  and  “dumb”  display  heads,  had  been  proposed. 

The  ecu  was  a  candidate  for  replacement  by  a  major  upgrade  of  the  C-1 7  CNI  subsystems.  As  with  the 
F-15’s  FCCs,  the  C-17’s  FCC  hardware  had  been  upgraded,  and  its  low  volatility  and  safety  critical 
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software  presented  complex  upgrade  retest  problems.  The  CCU  was  eventually  chosen  as  the  target 
domain  for  lULS  Task  2  emulation. 

The  CIP  was  under  development  (first  flight  was  scheduled  for  Summer  1997)  to  replace  the  extant 
Mission  Computers  whose  hardware  was  obsolete  and  overloaded.  Software  upgrades  were  going  Into 
both  systems  In  parallel. 

A  prime  consideration  In  the  selection  of  the  avionics  component  to  be  used  for  the  lULS  demonstration 
was  potential  for  transition  to  an  EMD  program.  Specifically,  the  lULS  goal  was  not  only  to  demonstrate 
technology  on  a  significant  avionics  upgrade  challenge  problem,  but  also  to  transition  the  technology  to  an 
emerging  EMD  opportunity. 

5.3  Customer  Upgrade  Requirement 
5.3.1  C-17APM 

The  APM  was  a  prime  candidate  for  the  demonstration  because  It  represented  a  domain  of  avionics 
subsystems  that  does  Internal  data  collection  and  formatting,  and  bridging  of  multiplex  busses.  It  was 
essentially  a  state  machine  similar  to  the  F-15’s  AlU,  but  It  did  more  processing  for  caution  and  warning 
generation  Including  the  calculation  for  a  stall  warning.  It  supported  Interactive  maintenance  mode  formats 
on  cockpit  displays  via  the  CIP,  and  supplied  data  to  the  C-17’s  recorders. 


Figure  32.  APM  Context 

Besides  the  Avionics  and  Warning  And  Caution  System  (WACS)  1553  MUXs,  the  APM  had  major  serial 
Interfaces  via  ARINC  573  with  the  Aircraft  Integrated  Data  System  (AIDS  -  maintenance  data  recorder), 
and  via  ARINC  429  with  the  Electronic  Engine  Controls  (EECs),  Flight  Test  Recorder  (FTR),  and  Cabin 
Pressure  Sensors/Controllers  (CPSs).  ARINC  422  channels  were  used  with  Engineering/Fllght 
Development  Units  for  aircraft  testing.  The  APM  received  many  analog  sensor  Inputs  for  conversion  such 
as  AOA,  control  surface  positions  and  acceleration;  some  were  used  for  generating  the  stall  warning 
discrete  output  to  the  pilot’s  and  co-pllot’s  stick  shakers. 

The  following  figure  represents  the  major  hardware  components  of  the  APM.  They  were  contained  on  one 
“mother  board”  linked  with  local  common  address,  memory  and  control  busses. 
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Figure  33.  ARM  Flardware  Configuration 

It  was  a  speciai  purpose  processor  whose  architecture  was  customized  for  this  appiication.  The  JOVIAL 
OFP  including  boot  program  were  in  the  176K  static  EEPROM.  The  32K  EEPROM  was  used  to  store 
aircraft  fault  data  that  was  retained  at  power-off  between  flights. 

Early  in  Task  2  the  lULS  customer  and  the  C-17  SPO  were  briefed  on  Task  2  plans  for  the  C-17.  The 
result  of  the  Task  1  analysis  for  the  C-17  avionics  system  was  the  recommendation  of  an  ARM  upgrade 
demonstration.  Several  factors  supported  this  recommendation.  The  OFP  was  well  designed  JOVIAL 
from  Hamilton  standard  and  Boeing  had  taken  over  doing  software  updates  to  the  system.  The  Cl 7 
project  was  considering  an  upgrade  to  the  ARM  with  the  objectives  of: 

•  Mitigating  the  hardware  obsolescence  of  the  1750  processor  and  other  components,  and  replacing  the 
JOVIAL  software  and  its  SEE. 

•  Migrating  its  features  into  the  CIP  as  a  general  integration  of  federated  subsystems. 

The  Hybrid  approach  was  ruled  out  since  the  ARM  has  non-separable  obsolete  components  and  a 
software  architecture  that  is  customized  for  the  hardware  configuration.  A  rehost  option  was  briefed  as  a 
possibility  but  not  the  preferred  approach.  The  JOVIAL  OFP  could  be  rehosted  and  a  JOVIAL  compiler  for 
the  COTS  target  existed.  However,  the  cost  factors  for  a  rehost  indicated  it  was  not  the  best  solution.  In 
addition,  the  F-15  demonstration  was  a  rehost  and  better  experience  with  the  lULS  tools  would  be 
obtained  by  using  a  different  approach  for  the  C-17. 

The  recommendation  for  an  ARM  upgrade  demonstration  was  the  emulate  approach  shown  in  the  following 
figure.  The  ARM  was  the  most  cost-effective  candidate  for  this  approach  in  the  C-17.  Its  upgrade  would 
serve  as  a  model  for  the  upgrades  of  other  specialized  C-17  and  F-15  subsystems  such  as  the  Avionics 
Interface  Unit.  The  Task  1  emulator  analysis  and  modeling/simulation  indicated  that  the  approach  was 
viable  in  terms  of  emulator  and  application  resource  usage  on  a  COTS  processor.  A  processor  system 
and  avionics  test  environment  would  be  available  for  a  “hot  bench”  demonstration  at  the  C-17  engineering 
facility.  The  demonstration  was  tentatively  planned  for  the  first  quarter  of  CY99. 
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C-17  Demonstration 

Partial  Emulation/Rehost  On  C-17  Avionics  Bench 


Tornado 


VMEbus 


Figure  34.  Planned  C-17  APM  Demonstration 

It  was  also  briefed  that  the  scope  of  wrapping/emulating  the  complete  A/PDMC  OFP  for  C-17  was  beyond 
the  lULS  program  scope/budget.  In  particular,  complete  I/O  emulation  (discrete,  analog,  etc.)  would  drive 
the  cost  beyond  available  lULS  funding.  The  recommended  demonstration  entailed  a  partial  OFP  (Engine 
Monitoring  function)  emulation.  However,  the  recommended  partial  OFP  emulation  would  be  sufficient  to 
assess  the  TRW  emulator  technology  and  verify  the  lULS  process.  In  addition,  the  recommended  program 
was  scaleable  to  a  full  A/PDMC  OFP  demonstration,  shown  in  the  following  figure,  should  funding  become 
available  in  FY99. 


C-17  Demonstration  Option 

TRW  Replacement  Emulation/Rehost  On  C-17  Avionics  Bench 


A/PDMC  Avionics  Bus  WACS  Bus  Test  ADS 


Figure  35.  Optional  C-17  APM  Demonstration 
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5.3.2  C-17CCU 

Subsequent  evaluation  by  the  C-17  SPO  indicated  that  the  Communications  Control  Unit  (CCU)  was  a 
more  viable  upgrade  candidate  than  the  APM.  At  that  time  the  APM  hardware  obsolescence  problems  had 
been  mitigated  for  the  short  term.  The  SPO  believed  that  the  CCU  was  more  likely  to  be  upgraded  and 
evolve  to  an  open  system  architecture.  Addition  of  GATM  and  other  new  functionality  would  drive  a  CCU 
upgrade  before  an  APM  upgrade.  The  CCU  would  provide  an  interface-rich  complex  test  of  emulator 
capabilities.  The  CCU  is  a  well-documented  OFP  and  is  functionally  separable  into  essentially  independent 
major  components.  The  functionally  separable  nature  of  the  CCU  OFP  made  it  an  ideal  candidate  for  a 
phased  approach  to  upgrade  and  incremental  demonstration  of  the  utility  of  the  emulation  approach  to 
rehosting  OFP  components  to  COTS  hardware.  Through  a  series  of  discussions,  and  execution  of  a  cost 
benefit  analysis,  the  demonstration  was  redefined  with  the  CCU  as  the  target  for  emulation  and  wrapping. 
The  cost  benefit  analysis  was  also  instrumental  in  securing  additional  funding  required  to  carry  the 
demonstration  through  execution  and  verification.  Subsequently,  a  program  plan  evolved  under  which: 

•  The  CCU  emulation  would  be  carried  through  a  laboratory  demonstration  of  wrapped  Radio  Control 
Function  (RCF)  of  CCU  operating  on  PowerPC  under  lULS  funding  (see  following  figure) 

•  Analysis  of  RCF  emulation  problem  to  verify  applicability  of  emulation  technology  to  CCU  upgrade 

•  Demonstration  to  gauge  utility  of  emulation  technology  and  provide  initial  metrics 

•  Demonstration  to  provide  final  gate  before  execution  of  TDs 


Card  Rack 


Figure  36.  CCU  Laboratory  Demonstration  Concept 

•  Two  Technology  Demonstrations  would  be  executed  under  separate  funding 

•  The  first  (TD-1)  would  demonstrate  integration  of  emulation  wrapped  RCF  on  PowerPC  in  CCU 
compatible  VME  chassis  at  the  Avionics  Software  Integration  Facility  (ASIF)  -  Long  Beach 

•  The  second  (TD-2)  would  demonstrate  full  emulation  wrapped  CCU  functionality. 

5.3.3  C-17CIP 

The  CIP  was  also  a  good  candidate  because  it  (like  the  F-15’s  VCC)  was  a  fairly  typical  mission 
processor.  It  was  unique  to  current  military  transports  in  that  it  was  COTS  hardware  and  contained  an 
OFP  written  in  Ada83.  It  also  represented  a  mission  computer  software  domain  that  did  not  have  detailed 
display  format  driver  components  and  worked  in  conjunction  with  “smart”  cockpit  displays.  There  are  two 
CIPs  in  a  C-17,  which  are  synchronized  and  can  backup  each  other. 
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Figure  37.  CIP  Context 

The  CIP  hardware  was  a  new  unit  from  Lockheed  Martin  containing  6U  VME  cards  in  a  VME-64 
backpiane/chassis  with  many  spare  siots.  The  initiai  configuration  as  shown  in  the  foiiowing  figure  inciuded 
a  Computer  Processor  Moduie  containing  an  R4400  and  its  OFP  on  SUROM,  an  Input/Output  Processor 
aiso  containing  an  R4400  with  two  1553  Channeis,  and  an  Input/Output  Moduie  for  discrete  I/O. 


1553  Channel  1&2  Discrete  I/O 


Growth 


Figure  38.  CIP  Hardware  Configuration 

The  CIP  OFP  was  mostly  Ada83  with  some  C  driver  components.  It  had  been  translated  from  the  JOVIAL 
MC  OFP,  using  a  tool  provided  by  Hughes.  It  contained  the  VxWorks  real-time  operating  system  (RTOS) 
from  Wind  River  Software  and  was  developed  on  Sun  Workstations  using  a  Rational  host  compiler  and 
Green  Hills  target  compiler.  The  CIP  OFP’s  major  features  were  similar  to  those  of  combat  aircraft  OFPs. 
The  major  differences  were  that  the  CIP  provided  more  navigation/guidance  modes  and  flight/mission 
planning  services  that  are  typical  of  transport  aircraft,  but  did  not  support  weapon  delivery. 

CIP  Features 

•  System  Management  and  Monitoring 

•  Communications  Management 

•  Navigation 

•  Guidance 

•  Controls  and  Displays 
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•  Aircraft  Performance  Prediction 

•  Flight  Planning 

•  Database  Management 

•  Data  Interfaces 

•  1553  Busses 

•  Discrete  Interfaces 

Potential  C-17  Upgrades  Which  Affect  CIP  and  APM  Features 

•  Traffic  Alert  and  Collision  Avoidance  System  (TCAS) 

•  Autonomous  Landing  Guidance 

•  Replacement  of  cockpit  displays 

•  MD-17  Commercialized  Avionics 

•  Global  Air  Traffic  Management  (GATM)  avionics 

•  Special  Forces  avionics 

Although  the  decision  was  made  not  to  pursue  a  CIP  upgrade  using  lULS  tools  the  CIP  eventually  played  a 
key  role  in  the  lULS  Technology  Demonstrations.  As  described  below  under  TD-1  and  TD-2,  the  decision 
was  made  to  redefine  TD-2  to  focus  on  integration  of  the  TD-1  hardware  and  software  into  the  CIP. 
Results  of  these  attempts  are  described  under  TD-2  below. 

5.4  ecu  Laboratory  Demonstration 

The  initial  effort  in  support  of  the  C-17  CCU  emulation  demonstration  was  the  CCU  Laboratory 
Demonstration  which  was  executed  under  lULS  funding  to  demonstrate  the  viability  of  the  emulation 
approach  to  the  CCU  upgrade.  The  CCU  Laboratory  Demonstration  included  two  phases: 

•  In  the  first  phase  an  analysis  of  the  emulation  of  the  RCF  of  the  CCU  was  executed 

•  In  the  second  phase,  emulation  technology  was  applied  to  develop  wrapper  software  for  the  RCF 
function  of  the  CCU  and  performance  was  demonstrated  in  a  laboratory  environment. 

As  shown  in  the  following  figure,  the  program  was  structured  such  that  successful  completion  of  the 
domain  analysis  (Phase  1)  was  an  entrance  criterion  for  the  demonstration  phase  (Phase  2).  The  figure 
also  shows  the  various  elements  required  for  successful  execution  of  the  Phase  2  demonstration.  Finally 
successful  completion  of  the  Phase  2  demonstration  was  specified  as  an  entrance  criterion  for  Phases  3 
and  4. 


<  Phase  2  -  Gate  > 


Figure  39.  CCU  Demo  Gates 
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5.4.1  Phase  1 

The  Phase  1  analysis  consisted  of  the  following: 

•  Domain  Analysis 

•  Evaluation  of  the  Utility  of  the  Emulator 

•  Develop  Demonstration  Plan. 

The  domain  analysis  considered  all  CCU  functionality,  software  and  interfaces  with  major  focus  on  the  RCF 
functions.  Particular  attention  was  paid  to  the  1553  RCF  functions  and  discretes.  The  analysis  determined 
specific  interfaces  to  be  supported  and  functions  to  be  emulated.  The  emulator  evaluation  was  tightly 
coupled  with  the  domain  analysis  since  emulator  capabilities  and  modifications  were  integral  to  decisions 
regarding  scaling  of  the  functionality  to  be  emulated.  The  emulator  evaluation  identified  required 
modifications  to  the  TRW  RePLACE  tool  and  API,  major  risk  areas  and  provided  ballpark  estimates  of  cost 
and  schedule.  TRW  participated  throughout  the  domain  analysis  in  their  role  of  emulator  developer.  The 
results  of  the  domain  analysis  /  emulator  evaluation  was  a  set  of  requirements  for  each  demonstration 
phase  which  were  executable  within  program  resources.  The  consensus  of  the  team  was  that  the  Phase  2 
demonstration  should  focus  on  wrapping  of  the  RCF  with  simulated  1553  interfaces  and  radios.  The 
demonstration  should  be  executed  at  the  C-17  SPO.  Phase  3  would  deliver  a  ruggedized  PowerPC 
system  and  emulation  wrapping  with  real  vice  simulated  1553  interface  devices  (radios).  Phase  4  would 
deliver  a  wrapped  CCU  system  with  audio  and  radio  control  functions  on  a  ruggedized  PowerPC.  The 
Phase  3  and  4  demonstrations  would  be  executed  in  the  AIA  at  Long  Beach.  A  top-level  description  of  the 
content  of  the  three  demonstrations  is  shown  in  the  following  figure.  The  figure  includes  changes  in  content 
which  are  discussed  under  TD-1  and  TD-2  below. 
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Figure  40.  Demonstration  Definition 

The  output  of  the  domain  analysis  /  emulator  evaluation  were  used  to  develop  the  demonstration  plan.  The 
team  conclusion  was  that  the  problem  was  low  risk  within  the  schedule  and  budget  available.  The 
demonstration  plan  defined  the  approach  for  demonstrating  and  testing  emulated  functions  including  test 
signal  collection  needs  and  simulation  approach.  The  plan  defined  the  content  of  the  demonstrations  in  the 
following  areas:  interfaces,  functions,  displays,  risk.  It  included  a  task  schedule  and  critical  path  analysis. 
The  schedule  and  top-level  content  are  shown  in  the  following  figure.  As  described  below,  the  content  and 
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dates  for  TD-1  and  TD-2  changed  in  response  to  programmatic  infiuences.  These  changes  are  refiected  in 
the  figure. 
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Figure  41 .  Demonstration  Scheduie 

The  results  of  Phase  1  were  reviewed  with  the  lULS  and  G17  customers  and  it  was  agreed  that  the 
program  should  enter  Phase  2. 

5.4.2  Phase  2 

The  Phase  2  demonstration  was  designed  to  verify  applicability  of  the  lULS  emulator  technologies  and 
processes  to  the  G17  CCU  domain.  Exercise  of  limited  CCU  functionality  and  a  subset  of  the  external 
interfaces  was  established  as  an  entrance  criterion  for  development  of  a  more  complete  solution  under  the 
Weapon  System  Software  Technology  Support  (WSSTS)  contract.  The  WSSTS  effort  would  include 
Phases  3  and  4  of  the  demonstration.  Phases  3  and  4  are  also  known  as  C-17  Technology 
Demonstrations  1  and  2  or  TD-1  and  TD-2. 

The  focus  of  Phase  2  was  to  demonstrate  emulation  of  MIL-STD  1553  I/O  including  emulated  UHF  and 
VHF  radio  control.  The  ability  to  communicate  over  the  RS-232  interface  was  also  a  demonstration  goal. 
The  following  figure  provides  a  logical  view  of  the  C-17  Integrated  Radio  Management  System  (IRMS)  with 
the  Phase  2  demonstration  elements  shaded.  The  MCK/MCD  elements  are  the  Mission  Control  Keyboard 
and  Mission  Control  Display,  which  were  emulated  in  the  demonstration  and  used  to  exercise  the  MIL-STD 
1553  interface. 
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ecu  NO.  2 


Figure  42.  C-17  IRMS  Elements  Demonstrated  in  Phase  2  (Logical  View) 

In  the  Phase  2  demonstration  configuration,  a  commercial  VME  Chassis  containing  a  PowerPC  603e  with 
Ethernet,  200  MHz  Dual  1553  and  single-channel  RS-232  interfaces  acted  as  CCU  No.  1.  The  CCU 
Legacy  OFP  wrapped  with  TRW’s  RePLACE  1750  Emulator  executed  on  the  VME-enclosed  PowerPC.  A 
laptop  computer  was  tied  into  the  RS-232  interface  to  support  Aircrew  Laptop  Computer  (ALC)  Database 
Download.  A  separate  PC,  which  acted  as  the  MCD/MCK  emulator,  was  tied  into  the  MIL-STD  1553 
interface.  Another  laptop  was  tied  into  the  MIL-STD  1553  interface  and  connected  to  the  VME  Chassis  by 
Ethernet.  This  latter  laptop  executed  TRW’s  VIEWstation  Debug  Toolset.  UHF  and  VHF  radio  control  was 
emulated  using  the  PASS-3000  1553  Bus  Emulator.  The  physical  view  of  the  Phase  2  Demonstration 
Configuration  is  shown  in  the  following  figure. 
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Figure  43.  Phase  2  Demonstration  Configuration  (Physicai  View) 


The  Phase  2  Demonstration  executed  a  subset  of  CCU  OFP  functionaiity  seiected  to  satisfy  the  objective 
of  vaiidating  the  emuiation  approach  on  an  expedited  scheduie.  The  foiiowing  figure  shows  CCU  OFP 
Components  and  indicates  the  extent  to  which  they  were  exercised  in  the  demonstration. 


The  primary  concern  regarding  emuiator  performance  was  in  the  area  of  I/O.  The  buik  of  the  modification 
to  the  existing  1750A  emuiator  performed  to  support  the  Phase  2  Demonstration  were  in  this  area.  The 
foiiowing  figure  provides  an  overview  of  the  emuiator  I/O  used  in  the  demonstration. 
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•  I/O  Device  Objects  Written: 

-  BC1553  RT1553  BCRT  Discretes 

-  Audio  Discretes  ANDVT  Discretes  KY  Discretes 

-  Anaiog  Transponder  SATCOM  Discretes  Seriai  lO 

-  SBC  Discretes 

•  Status  of  I/O  Devices 

-  Completed  Fully  Functional  1553  Bus  Controller  Device  Class  (RT  Class 
implemented,  to  be  tested  in  next  phase  w/dual  CCD) 

-  Completed  Fully  Functional  Serial  lO  Class 

-  Stubbed  Out  Most  Discretes  with  Static  Values 

•  OFF  Code  that  has  been  bypassed  with  "thunks" 

-  Startup02  Replacement  0x01140  0x00002 

-  IBitOI  Replacement  0x02F79  0x00157 

-  RegReadbkOI  Replacement  0x022EA  0x00049 

-  XIOREDBLACK  Replacement  0x01 05F  OxOOOOA 


Figure  45.  Overview  of  Emuiated  I/O 

The  demonstration  procedure  entaiied  8  steps: 

•  Loading  of  Emuiator  and  CCU  OFF 

•  Coid  Startup  of  CCU  OFP 

•  Operation  of  MCK/MCD  using  MCK/MCD  Emuiator 

•  Upioading  of  Comm  Database  from  Aircrew  Laptop  Computer 

•  Reviewing  of  Comm  Database  on  MCD 

•  Viewing  UHF/VHF  Radio  Controi  1553  Data 

•  Reviewing  Fauit  List  on  MCD 

•  Viewing  Emuiator  Performance 

The  Phase  2  demonstration  was  performed  at  the  C-17  SPO  on  12  March  1999.  The  foiiowing  functions 
were  demonstrated: 

•  Mission  Controi  Keyboard  (MCK)  /  Mission  Controi  Dispiay  (MCD)  operation  -  verified  the  abiiity  to 
communicate  on  the  MIL-STD-1553  bus 

•  Communications  Database  upioading  -  verified  the  abiiity  to  communicate  over  the  RS-232  interface 

•  Dispiay  upioaded  Communications  Database  -  verified  the  abiiity  to  use  upioaded  database 
information 

•  Controi  an  emuiated  radio  -  verified  the  abiiity  to  communicate  with  devices  on  the  MIL-STD-1553  bus 

•  Demonstrate  status  functionality. 

There  were  several  lessons  learned  from  the  demonstration: 

•  Lack  of  discrete  interfaces  &  real  hardware  devices  requires  carefully  tweaking  stubbed  out  discretes 
&  careful  modeling  of  some  of  them 

•  Having  LRU/OFP  domain  expertise  on-site  during  integration  will  accelerate  the  effort 

•  Adequate  time  should  be  allocated  to  assemble  &  checkout  the  various  components  of  the  test 
environment 

•  Care  should  be  taken  to  ensure  that  the  OFP  and  its  documentation  are  consistent  (same  version). 

This  can  be  a  quite  common  problem  when  very  old  legacy  software  is  used,  and  the  documentation 
has  not  kept  up  with  the  pace  of  software  changes 

•  Getting  the  OFP  up  &  running  can  be  successfully  accomplished  in  a  very  short  time  period  after  i/o 
devices  have  been  completed  (2-3  weeks  in  this  case). 

The  demonstration  made  to  the  C-17  SPO  was  a  major  success.  The  program  was  described  by  Chris 
Blake  (then  Technical  Director)  "This  is  great  work.. .(to  AFRL)  your  6.3  funding  will  get  even  tighter,  but 
we  can't  let  go  of  this  one. ..(to  Boeing)  I'm  offering  to  be  your  launch  customer. ..(to  Hartman  -  Chief 
Systems  Engineer)  let's  make  this  happen." 
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Following  the  execution  of  Phase  2,  initiation  of  the  Technology  Demonstration  Program  (Phases  3  &  4) 
was  approved.  The  major  areas  of  risk  were  all  considered  low  after  completion  of  the  demonstration,  as 
shown  in  the  following  figure. 


Risk  Factor 

Severity 

Mitigation  Plan 

Fidelity  Of 
Emulation 
Including  Timing 
Dependent  Code 

Low  - 

Moderate 

■  Analysis  Of  OFP  And  Utilization  Of 
Thunks  &  Wait  Loops  -  4  thunks  installed 

■  Addressed  During  Phases  2  &  3 

Adequate 
Throughput  For 
Emulator,  1/  O 
Wrapper,  &  New 

C  Code 

Function(S) 

Low  - 

Moderate 

■  Emulator  Measured  <=10%  Of  Available 
Throughput; 

■  I/O  Wrapper  Performance  To  Be 

Measured  In  Phase  2  (<15%  Expected) 

■  Emulator  running  at  6.5  MIPS  w/  lO 
wrappers  (~  85%  excess  margin) 

*-Audio  Code  Performance  To  Be 

Measured  &  Used  To  Project  OS-CCU 

Perf. — (  <  25%  Expected)not  needed 

■  Addressed  During  Phases  2,3,4 

Interfacing  New  C 
Code  To  Existing 
Jovial  Object  Code 

Low 

■  CCU  OFP  Is  Well  Structured  With  Logical 
Interface  Boundaries  Between  Functions; 

■  Debug  Toolset  Assists  User  In  Hooking 

Into  Legacy  Code 

■  Addressed  During  Phase  2 

Figure  46.  Post  Demonstration  Risk  Assessment 

5.5  C-1 7  Technology  Demonstration  1  (TD-1) 

lULS  TD-1  built  upon  the  success  of  the  Phase  2  demonstration.  TD-1  was  designed  to  accomplish  all 
objectives  of  the  Phase  2  Demonstration,  but  in  a  more  realistic  environment  and  with  additional 
functionality.  Significant  changes  from  the  Phase  2  Demonstration  to  TD-1  included: 

•  Emulator  and  CCU  OFP  operation  in  a  workstation  environment 

•  Emulator  and  CCU  OFP  operations  in  COTS  Replacement  Box  (CRB)  environment 

•  CRB  Connected  to  the  IRMS  Subsystem  Evaluation  Station  in  place  of  either  CCU 

•  Operation  of  MCK/MCD  using  MCK/MCD  Emulator 

•  Operation  with  both  real  and  emulated  MCK/MCDs 

•  Operation  of  CRB  with  actual  C-1 7  Line  Replaceable  Units  (LRUs)  including  second  CCU,  ICS 
panels,  CNC  panels  and  radios 

•  Uploading  of  Communications  Database  with  current  or  follow-on  ALC 

•  Reviewing  Communications  Database  on  MCD 

•  Preset  selection  and  loading  for  all  radios  including  SATCOM 

•  ARC-210,  UHF,  VHF,  HF,  and  IFF  Radio  Control 

•  Discrete  wires  individually  control  power  and  antenna  selection  for  each  radio 

•  Reviewing  fault  list  on  MCD 

•  Fault  History  recorded  and  displayed  identically  to  second  CCU 

•  Interactive  and  non-interactive  Build-In-Test  controlled  by  CRB  for  each  interfacing  LRU 

•  Audio  functions  undisturbed  in  second  CCU 

•  CCU  2  controls  audio  routing  for  all  radios 

•  CIP/CCU/CRB  1553  handshake  undisturbed 
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•  EMCON,  TACAN,  ADF  function  normally 

The  following  figure  gives  a  logical  view  of  the  CCU  Demonstration  Plans  for  TD-1  and  TD-2.  The  Phase  2 
Demonstration  is  included  for  reference.  As  can  be  seen  from  the  figure  each  of  the  TDs  add  to  the 
demonstration  content.  It  should  also  be  noted  that  this  logical  view  does  not  tell  the  complete  story.  For 
instance,  CCU  No.  1  appears  the  same  for  the  Phase  2  Demonstration  and  TD-1  on  the  logical  view.  In 
actuality,  the  TD-1  implementation  was  of  higher  fidelity  in  this  area  as  described  below  in  the  discussion  of 
the  COTS  Replacement  Box. 


CCU  NO.  2  (Real  CCU) 


Figure  47.  CCU  Demonstration  Plan  (Logical  View) 

The  lULS  TD  Program  was  structured  with  TD-1  as  a  gate  for  TD-2.  The  following  figure  depicts  this  gate 
structure  along  with  the  principal  elements  of  TD-1 . 
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A  key  element  of  TD-1  was  the  CCU  COTS  Replacement  Box  (CRB).  The  CCU  CRB  Is  a  computing  device 
capable  of  functionally  emulating  either  legacy  CCU  LRU.  The  rear  panel  of  the  chassis  holds  connectors, 
which  provide  connection  to  the  CCU  I/O  signals.  The  CCU  CRB  also  connects  to  a  Personal  Computer 
(PC)  known  as  the  CRB  User  Console  that  executes  download,  test,  and  control  software.  The  PC 
connects  to  the  CRB  via  both  Ethernet  and  RS-232  connections.  A  critical  component  of  the  CCU  CRB  Is 
the  processor  board,  which  executes  the  RePLACE  1750A  Dual  Instruction  Set  Computer  (DISC)  software 
and  the  CCU  OFP.  The  processor  board  Is  a  SP-103  Lockheed  Martin  Federal  Systems  (LMFS) 
PowerPC  603e  200MHz  single  board  computer  housed  In  a  VME64  chassis.  The  CCU  CRB  contains  I/O 
Interface  boards  to  provide  the  I/O  signals  required  for  emulation  of  the  legacy  C-17  CCU.  The  I/O 
Interface  boards  send  and  receive  the  same  signals  as  the  legacy  C-17  CCU  LRU  so  that  the  CCU  CRB 
can  serve  as  a  functional  drop-ln  replacement  for  the  C-17  CCU  LRU.  The  CCU  CRB  communicates  with 
an  external  PC  used  as  a  User  Console.  The  User  Console  acts  as  a  file  server,  providing  software  and 
data  files  needed  by  the  CCU  CRB.  The  User  Console  also  downloads  and  starts  the  CCU  CRB  software. 
The  CRB  replaces  the  commercial  VME  Chassis,  PowerPC  and  Interfaces  used  In  the  Phase  2 
Demonstration. 

The  following  figure  shows  the  TD-1  Demonstration  Configuration.  Comparison  with  the  Phase  2 
configuration,  shown  previously,  highlights  many  of  the  changes.  The  figure  shows:  the  availability  of  dual 
MCK/MCD’s  vice  the  emulated  MCK/MCD  used  In  the  Phase  2  demonstration,  utilization  of  the  MCK/MCD 
to  host  the  VIEWstatlon  toolset  and  perform  the  ALC  Database  Download,  single  or  dual  CCU 
configuration,  and  the  Inclusion  of  real  radios.  Not  visible  from  the  figure  Is  the  contribution  of  the  CRB. 
The  CRB  Includes  the  VME  Chassis  etc  and  supports  testing  of  the  radio  discrete  Interfaces. 
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Figure  49.  TD-1  Demonstration  Configuration 


TD-1  was  compieted  in  August  1999.  The  foiiowing  items  were  demonstrated: 

•  Operation  of  CRB  acting  as  a  singie  CCU 

•  Duai  CRB  -  CCU  operation 

•  Communications  Database  upioad  with  current  and  foiiow-on  ALC 

•  Operations  with  MCK/MCD,  CNC,  ICS 

•  Operations  with  aii  radios  (ARC-210,  UHF,  VHF,  HF)  and  IFF 

•  Audio  controi  and  switching  with  CRB  and  second  CCU  controiiing  audio  as  “Aiternate” 

Initiai  bench-marking  performance  indicated  6.0  MIPS  compared  to  6.5  MIPS  at  March  demonstration, 
iargeiy  due  to  additionai  processing.  This  represents  approximateiy  a  90%  reserve  above  the  iegacy 
1750A  processor. 

There  were  no  major  anomaiies  during  the  testing.  Four  minor  anomaiies  were  observed  and  were 
subsequentiy  dispositioned.  The  decision  was  made  to  proceed  with  TD-2. 

5.6  C-17  Technology  Demonstration  2  (TD-2) 

By  the  time  of  initiation  of  TD-2  the  demonstration  had  undergone  considerabie  redefinition.  The  originai 
pian  (12/98)  had  been  to  add  TCOMMS  Audio  Switching  in  TD-2.  Before  initiation  of  TD-1,  this  pian  had 
been  revised.  Audio  switching  was  eiiminated  because  of  Teiephonics  costs  and  interface  to  the  APX-105 
Transponder  was  added.  The  originai  approach  emphasized  use  of  Teiephonics  TCOMMS  software  to 
perform  the  audio  switching  function,  and  the  use  of  emuiation  for  the  remaining  radio  controi  functions. 
Audio  switching  functionaiity  costs  based  on  integrating  off-the-sheif  TCOMMS  software  were  substantiaiiy 
above  avaiiabie  funding  and  made  this  originai  eiement  of  TD-2  impossibie  to  execute.  As  an  aiternative, 
Boeing  Long  Beach  recommended  (and  we  received  C-17  SPO  concurrence)  to  repiace  audio  functionaiity 
with  execution  of  CCU  functionaiity  by  integrating  CCU  COTS  processor  into  the  CIP.  The  rationaie  for 
these  changes  were  the  non-recurring  costs  for  the  audio  switching  and  the  C-17  Program  interest  in  CIP 
integration  as  a  potentiai  end-state. 

The  TD-2  kick-off  was  heid  foiiowing  the  TD-1  demonstration  on  26  August  and  served  to  re-prioritize 
some  of  TD-2  activities  foiiowing  the  success  of  TD-1.  The  priorities  were  deveioped  jointiy  by  the  C-17 
SPO  and  the  C-17  program  at  Long  Beach  and  were  seiected  to  better  enabie  C-17  to  incorporate  resuits 
of  the  Tech  Demo  program  in  their  C-17  Open  Systems  Communication  architecture  study.  Specificaiiy,  the 
foiiowing  priorities  were  made:  1)  Transition  CCU  OFP  baseiine  from  8.2  to  8.3;  2)  Incorporate  emulation 
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wrapped  OFP  into  CIP;  3)  Incorporate  C  language  fixes  to  8.3  software  into  the  emulation  wrapped  OFP; 
4)  Investigate  ANDVT.  The  incorporation  of  APX-105  radar  transponder  was  viewed  by  C-17  as  of  only 
limited  utility,  since  during  TD-1  we  have  already  demonstrated  interface  of  wrapped  software  with  a  wide 
variety  of  other  1553  devices. 

Initial  integration  for  TD-2  was  conducted  at  Long  Beach  on  27  -  30  September  1999.  The  activity 
included:  1)  Incorporation  of  CCU  OFP  baseline  8.3  into  the  CRB;  and,  2)  Initial  CIP  integration  of  SP-103 
and  discretes  into  the  CIP.  The  upgrade  of  CCU  baseline  from  8.2  to  8.3  proceeded  very  smoothly. 

Initial  integration  of  the  CRB  components  into  the  CIP  did  not  go  as  smoothly  as  desired.  The  SP-103  was 
successfully  integrated  into  the  CIP  using  a  VME  extender  card.  However,  the  CIP  was  not  able  to  work 
with  both  the  SP-103  and  the  discrete  I/O  boards  installed  on  VME  extenders  in  the  CIP  chassis. 
Specifically,  the  CIP  would  either  go  into  a  degraded  mode  or  not  work  at  all  with  more  than  one  extender 
card  in  the  chassis.  This  appeared  to  be  due  to  system  losses  as  the  bus  was  extended.  Lockheed 
Martin  CIP  personnel  at  Long  Beach  reported  that  was  also  their  experience.  Also,  the  VMETRO  VME 
bus  analyzer  tool  did  not  fit  within  the  channel  guide.  The  discrete  boards  and  VME  repeater  boards  had 
card  layouts  that  allowed  component  contact  with  the  chassis.  To  accommodate  operation  in  the  CIP,  the 
discrete  card  layout  would  need  to  be  modified  to  utilize  less  board  space.  This  may  or  may  not  be  a 
problem  with  ruggedized  COTS  discrete  I/O  boards. 

Boeing  and  TRW  developed  two  plans  in  response  to  work  around  the  CIP  chassis  limitations:  1)  Plan  A; 
and  2)  Plan  B.  The  plans  were  documented  in  the  minutes  of  a  TIM  held  on  7  October  in  Dayton.  Through 
subsequent  evaluations.  Plan  A  was  identified  as  the  preferred  approach. 

The  following  figure  shows  the  approach  for  plan  A.  Briefly,  the  SP-103  board  would  be  installed  in  the 
CIP  chassis.  A  VME  Repeater  Master  card  would  be  installed  in  the  QP  and  connected  with  a  "Slave" 
card  in  the  CRB.  The  discrete  I/O  boards  would  be  installed  in  the  CRB.  In  essence,  this  is  the  same 
arrangement  as  a  CIP  integration  (assuming  that  ruggedized  discretes  would  fit  within  the  chassis). 


IMPLEMENTATION  PLAN  “A” 
VME  Repeater  Master  -  Slave 


CRB 


VME  Repeater  “Master”  Installed 
In  CIP.  “Slave”  in  CRB. 


LM  SP-103 
Moved  from  CRB  to  CIP 
Operating  on  Extender 


All  VME  bus  arbitration  occurs  In  CIP  Chassis 


Figure  50.  CRB  CIP  Integration  Plan 

Boeing  performed  a  second  integration  of  the  wrapped  Radio  Control  Function  (RCF)  in  the  CIP  starting  1 
November.  The  November  integration  activity  used  Plan  A  from  the  October  TIM.  The  second  integration 
activities  proceeded  with  limited  success  largely  due  to  the  somewhat  non-standard  VME  nature  of  the 
CIP.  TRW  and  Boeing  discussed  the  integration  issues  with  the  CIP  vender.  The  vendor  indicated:  1) 
Need  for  current  SP-103  drivers;  and  2)  Need  to  cut  traces  in  the  CIP  backplane.  Given  these,  they 
indicated  that  they  believed  the  integration  would  work. 
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Most  important,  Boeing  lULS  personnei  met  with  Boeing  G17  personnei  reiative  to  the  communication 
open  architecture  study  and  to  CIP  integration  progress.  They  described  their  efforts  in  CIP  integration 
and  reiayed  to  the  C-17  personnei  the  resuits  of  the  teiecon  with  the  CIP  vender.  Boeing  C-17  indicated 
that  he  couid  possibiy  get  a  spare  CIP  chassis  to  use  to  impiement  the  vender  suggestion.  They  aiso 
indicated  that  Boeing  C-17  no  ionger  consider  integration  into  the  CIP  as  either  a  mid  or  short-term 
objective.  Instead  they  viewed  it  as  a  very  iong  term  (C-17B)  type  of  goai.  Based  on  this  significant  C-17 
change  of  phiiosophy,  the  lULS  TD  program  decided  that  it  no  ionger  made  sense  to  pursue  integration 
activities  with  the  CIP  -  since  the  transition  story  had  for  practicai  purposes  evaporated.  Instead,  tech 
demo  efforts  focused  on  evaluation  of  the  emulation  tool  by  C-17  personnel  -  especially  in  its  support  of 
incorporating  new  C-r-i-  software.  Specifically,  we  believed  that  for  a  tech  transition  story  to  have  real 
longevity,  it  would  be  necessary  to  not  simply  emulate  a  legacy  system  -  but  also  to  demonstrate  how  the 
system  could  support  new  functionality  developed  using  modern  languages  including  C  and  C-r-i-. 

Following  initial  RePLACE  training  by  TRW,  Boeing  SAA/  engineering  personnel  initiated  their  development 
of  the  C-language  software  update  to  CCU  OFP  version  8.3.  They  continued  their  efforts,  and  were  able 
to  incorporate  their  update  into  the  wrapped  RCF.  The  software  engineers  wrote  a  draft  report  discussing 
their  observations  on  use  of  the  emulation  toolset.  The  report  indicated  that  the  engineers  were  able  to 
accomplish  their  job  without  difficulty.  The  report  also  provided  both  positive  observations  on  the  toolset, 
but  also  indicated  some  desired  updates.  It  also  indicated  that  successful  use  of  the  tool  required  domain 
expertise.  Some  potential  hardware  problems  with  the  CRB  were  reported  by  the  engineers  who  were 
working  the  C-language  update.  These  problems  have  been  resolved,  and  were  indicated  to  be  AISF 
related,  and  were  not  CRB  problems. 

The  final  disposition  of  TD-2  is: 

•  Ease  of  incorporating  update  of  legacy  Jovial  OFP  from  8.2  to  8.3  was  demonstrated 

•  Less  than  one  day  of  activity 

•  Successfully  executed  subset  of  System  Integration  Test  (SIT) 

•  Successful  execution  of  C-language  update  of  Jovial  Code 

•  Boeing  C-17  developed  challenge  problem 

•  Training  on  emulator  provided  by  Boeing  lULS  team  to  Boeing  C-17  software  developers 

•  Code  developed  and  initial  testing  by  Boeing  C-17  in  ASIF 

•  Successful  employment  of  technology  demonstrated 

•  Oct  99  integration 

•  COTS  Discrete  cards  did  not  fit  in  CIP  chassis  (impinged  on  wedge  locks) 

•  PowerPC  and  Discretes  on  Extender  Board  in  CIP 

•  CIP  operated  in  degraded  mode 

•  Probable  cause  losses  as  bus  extended 

•  Coincides  with  CIP  vender  experience 

•  Nov  99  integration 

•  PowerPC  on  extender  board  in  CIP 

•  Discretes  in  CRB 

•  Bus  conflicts 

•  Boeing/CIP  vender  discussions  indicated  cutting  of  traces  for  backplane  and  installation  of  latest 
PowerPC  driver  probably  required  but  could  be  made  to  work 

•  CIP  date  preceded  VME-64  bus  standardization 

•  C-17  Program  and  lULS  Team  Meeting  indicated  CIP  incorporation  of  RCF  no  longer  in  near  /  mid-term 
plan 

•  CIP  integration  efforts  suspended 

5.7  C-17  Communications  Open  System  Architecture  (COSA) 

The  C-17  program  embarked  on  the  COSA  program  during  the  summer  of  2000.  Figure  51  shows  a 
COSA  program  history. 
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1998 


< 

<1 

n 

PTP-077 
GATM  Initiatives 
8  Jan  98 
•GATM 

-  CPDLC,  ADS-A,TCAS, 
CMU,  AERO-I,  APX-100 
Mode  S 

•IRMS 

-  Legacy  CCU  analog 
audio  update 

-  Modified  ICS 

-  No  CNC  changes 

-  No  HRP  changes 

•~$85M  development  total 


Revised  PTP-077 
GATM  Initiatives 
24  Apr  98 

•GATM 

-  CPDLC,  ADS-A,TCAS, 
CMU,  AERO-I,  APX-100 
Mode  S 

•IRMS 

-  Legacy  CCU  unchanged 

-  ICS,  CNC  unchanged 

-  P/CP  HRPs  modified, 
SAT  audio  panel  added 

-  CCU  controls  Mode  S 

-  CIP  controls  AERO-I 

•~$61M  development  total 


1999 

ir  t 


C-17  Avionics 
Phase  I  OSA  Study 
Aug  -  Dec  98 


PTP-077 
SRR/JCB 
May  - Jun  98 

•AMC  /  SPO  concerned 
by  non-integrated  GATM 
solution 

•Recommended  launch  of 
separate  OSA  project  for 
IRMS 

•Nov  97  architecture  as 
baseline 


COSA  Study 
May  -  Dec  99 

•OSA  CCU 

-  Digitai  Audio 

-  Radio  Control  in  CCU 
•OSA  CNC 

•OSA  HRP 
•COSSI  ICS 

•Sat  audio  panel  deleted 
•No  1553  bus  architecture 
change 


Figure  51 .  COSA  Program  History 

The  COSA  study  conciuded  in  December  1999  and  resulted  in  the  initiation  of  an  ECP  for  implementation 
of  an  open  architecture  upgrade  of  the  C-17  communications  system.  Telephonies,  the  producer  of  the 
current  legacy  CCU,  was  selected  as  the  lead  subcontractor.  Key  elements  of  the  COSA  program  are 
identified  in  the  figures  below. 


□  System  upgrade  of  the  existing  integrated  Radio  Management 

□  OSA  CCU/Audio  Controi  Unit  repiaces  iegacy  CCU 

•Incorporates  digital  audio 

•Provides  secure  communication  operations  at  all  stations 
•System  control  functions  remain  in  the  CCU 
— 1 553  bus  control 

— Radio  selection,  operation,  and  control 
— MCD  user  interface 
•Mitigates  DMS/obsolescence 
•  Expansion  capability  to  support  future  requirements 
— GATM  Enhancements 
— VHF  Data  Link 

— Real  Time  Information  in  the  Cockpit 


Figure  52.  Key  COSA  Program  Features 

Additional  key  COSA  elements  are:  1)  1553  Bus  Architecture  remains  unchanged  with  no  impact  to  mission 
bus  loading  and  address  usage;  2)  Upgraded  CNC  and  ICS  control  panels  to  “soft  panel”  configuration; 
and  3)  CIP  functions  remain  unchanged.  These  latter  changes  were  consistent  with  the  lULS  TD  decision 
to  abandon  integration  of  CCU  functionality  into  CIP.  The  final  issue  in  the  COSA  program  was  the  role  of 


62 


lULS  technology.  Following  several  option  evaluation  TIMs,  the  Air  Force  decided  with  Boeing  C-17 
Program  concurrence  to  transition  lULS  emulation  technology  into  the  COSA  EMD  program.  Specifically, 
emulation  would  be  used  as  an  integral  element  of  the  development  for  the  radio  control  function.  A  key 
contributor  to  this  decision  was  the  potential  cost  savings  realizable  based  upon  a  REVIC  line  of  code 
analysis  of  alternatives.  However,  the  use  of  emulation  is  still  considered  by  the  G17  Program  as  a 
program  risk  that  needs  to  be  mitigated  through  additional  prototyping  and  testing.  The  figures  below 
display  the  COSA  development  approach  that  is  being  executed  during  the  EMD  program. 


Figure  53.  Key  COSA  /  lULS  Development  Processes 
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Figure  54.  Key  COSA  /  lULS  Development  Processes  (Cent.) 

These  figures  demonstrate  the  key  role  that  lULS  emulation  engine  will  have  in  the  COSA  program. 

5.8  C-1 7  Summary 

The  C-1 7  lULS  transition  is  a  work  in  progress.  Our  experience  indicates  that  transition  can  be  difficult  but 
is  achievable.  Successful  transition  requires  perseverance,  patience,  as  well  as  an  opportunity  to  perform. 
In  lULS,  we  started  down  the  tech  transition  path  with  the  C-1 7  program  as  our  partner.  As  a  team,  we 
changed  demonstration  challenge  problems  to  select  one  that  was  most  relevant  to  the  C-1 7  and  had  the 
greatest  potential  to  transition  to  EMD.  We  launched  the  lULS  tech  demonstration  program  using  a 
carefully  structured  four  phase  approach.  The  first  two  phases  were  executed  under  the  lULS  program. 
Entry  into  phase  3  was  conditional  upon  receiving  approval  of  the  C-1 7  program.  The  phase  2 
demonstration  was  an  unqualified  success.  It  received  high  praise  from  the  customer,  and  the  decision 
was  made  to  proceed  to  Phase  3  to  demonstrate  the  utility  of  lULS  emulation  in  the  C-1 7  avionics  labs. 
The  demonstration  provided  a  first  cut  shake  out  of  emulation  technology  and  indicated  significant  promise. 

At  the  end  of  phase  2,  the  C-1 7  Technical  Director  was  re-assigned  to  work  on  the  F-22  program.  In  a 
sense,  lULS  program  lost  one  of  its  greatest  technology  transition  backers  when  the  TD  left.  The  lesson  is 
that  tech  transition  to  some  degree  is  also  driven  by  advocacy  at  the  top  of  the  production  program,  and  is 
not  simply  driven  by  technology  success  or  maturity. 

Phases  three  and  four  of  the  tech  demonstration  program  were  executed  on  cost  and  on  schedule  with 
very  positive  results  obtained  by  execution  of  existing  C-1 7  test  procedures  using  the  CRB.  Even  with  this 
success,  the  transition  remained  in  the  balance.  Production  programs  are  by  their  very  nature  risk  averse. 
New  technologies  such  as  those  offered  by  lULS  are  seen  as  potential  risks  -  even  when  their 
performance  has  been  proven. 

Before  lULS  technology  was  selected  for  COSA,  a  number  of  options  were  considered  and  an  exhaustive 
trade  study  was  performed.  lULS  program  was  a  key  participant  in  these  studies,  and  we  were  able  to 
successfully  make  the  case  that  emulation  technology  was  ready  for  prime  time  and  should  have  an 
important  role  in  the  COSA  EMD  program.  One  of  the  central  arguments  that  was  made  was  that  use  of 


64 


emulation  is  a  risk  mitigator.  Re-engineering  of  the  proven  legacy  code  would  be  costly.  We  estimated 
using  REVIC  that  utilization  of  lULS  emulation  technology  could  potentially  save  the  COSA  program  on  the 
order  of  $3M.  This  estimate  was  based  on  comparing  costs  for  re-engineering  into  C/C-i-i-  approximately 
30,000  lines  of  code  vice  emulating  the  function  using  the  RePLACE  emulation  engine.  This  argument  was 
persuasive  and  was  important  not  simply  from  a  cost  perspective  -  but  more  from  a  risk  perspective.  The 
customer  may  save  money  by  using  emulation  -  but  counts  it  more  as  a  reserve  against  program  risk. 

One  of  the  important  factors  to  consider  is  that  in  this  lULS  technology  transition,  Boeing  had  key  roles  as 
both  the  technology  customer  (C-17  program  -  Long  Beach)  ,  and  the  technology  evaluator  (lULS  prime). 
This  provided  us  visibility  into  the  technology  transition  selection  process  that  would  have  been  impossible 
otherwise.  This  same  opportunity  would  have  likely  been  not  available  to  an  outside  technology  developer 
attempting  to  transition  technology  to  the  production  program. 

Some  other  thoughts  are  germane  to  transition  of  emulation  technology  to  a  production  program.  We  must 
first  remember  that  lULS  is  all  about  incremental  upgrade.  It  is  about  steps  along  a  migration  path  to  an 
open  system  and  taking  advantage  of  existing  legacy  software.  In  the  C-17  COSA  program,  the  customer 
needed  to  balance  their  desire  to  make  a  radical  open  system  architecture  upgrade  with  realities  of 
program  risk.  As  originally  bid  by  Telephonies,  COSA  envisioned  a  complete  re-engineering  of  CCU 
software.  Telephonies  did  not  intend  to  utilize  any  legacy  software  in  their  update.  The  C-17  program  was 
convinced  that  an  incremental  approach  afforded  them  a  better  short  term  solution,  provided  a  less  risky 
transition  path  to  the  desired  open  system  end  state,  and  allowed  them  to  utilize  a  substantial  investment  in 
legacy  software. 

The  COSA  program  is  taking  a  novel  approach  to  the  use  of  the  legacy  software  that  needs  to  be 
considered  as  the  lULS  emulation  model  evolves.  Specifically,  rather  than  starting  with  a  legacy  executive 
and  calling  new  native  functionality,  COSA  is  building  a  new  native  executive  to  call  selected  elements  of 
the  emulated  legacy  software.  While  this  might  be  considered  a  riskier  approach,  it  represents  the  C-17 
program  perspective  of  marching  toward  the  future,  and  the  emulation  engine  needs  to  adapt  and  support 
this  type  of  approach.  The  lesson  is  that  in  the  technology  transition,  the  customer  is  the  architect  of  the 
design  and  will  be  using  tools  in  ways  that  may  not  have  been  originally  intended.  Failure  of  the  technology 
to  perform  as  designed  even  in  the  face  of  new  applications  can  forestall  the  technology  transition.  Also, 
in  some  instances  the  failure  may  be  due  to  poor  or  not  maintained  legacy  software  design  in  the  first 
place. 
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6  Perimeter  Attack  Radar  Characterization  System  Analysis 

The  Perimeter  Attack  Radar  Characterization  System  (PARCS)  is  a  one-of-a-kind  sensor  system, 
deveioped  in  the  eariy  1970s  for  the  United  States  Army  Safeguard  Baiiistic  Missiie  Defense  System  by 
the  Western  Eiectric  Company,  a  part  of  Beii  System  at  the  time.  The  originai  system  design  caiied  for 
tweive  sites,  and  the  system’s  iogistic  support  was  pianned  with  that  in  mind.  With  the  signing  of  the  anti- 
baiiistic  missiie  treaty  between  the  United  States  and  the  Soviet  Union,  fuii  deveiopment  of  the  Safeguard 
system  haited.  The  PARCS  site,  at  Cavaiier,  N.D.  was  the  oniy  site  that  remained  open  and  aii  avaiiabie 
spares  were  sent  there.  These  spares  have  been  sufficient  to  maintain  the  site  through  the  present  time. 
However,  continued  operation  is  probiematic  due  to  imminent  exhaustion  of  the  suppiy  of  spares. 

Incrementai  upgrade  of  the  PARCS  system  software,  to  a  Commerciai  Off  The  Sheif  hardware 
architecture,  using  the  lULS  methodoiogy  and  tooiset,  was  identified  as  a  potentiai  avenue  of  reiief  for  the 
PARCS  hardware  obsoiescence  chaiienge.  The  hope  was  that  a  demonstration  of  the  appiication  of  lULS 
technoiogies  to  PARCS  couid  be  fit  into  the  Insertion  of  Embedded  Infosphere  Support  Technoiogies 
(lEIST)  program,  a  new  start  program  funded  by  the  Air  Force  Research  Laboratory.  This  pian  was 
contingent  upon  positive  answers  to  three  issues:  1)  that  incrementai  upgrade  of  PARCS  software  to  a 
COTS  hardware  suite  using  lULS  was  feasible  within  reasonable  budget  limitations,  2)  that  the  upgrade 
would  be  cost  effective,  i.e.  that  given  the  incremental  upgrade  of  the  PARCS  software,  the  PARCS 
system  would  be  a  viable  and  valuable  element  of  the  U.S.  space  infrastructure,  and  3)  that  informationally 
PARCS  could  be  fit  into  the  lEIST  Concept  of  Operations  and  scenario(s).  In  order  to  further  assess  the 
feasibility  of  this  approach,  a  limited  domain  analysis  of  PARCS  was  executed  under  lULS  funding.  This 
three  phase  domain  analysis  was  targeted  at  determining  the  feasibility  of  including  PARCS  in  lEIST  by 
answering  the  three  aforementioned  questions.  This  report  presents  the  results  of  that  analysis. 

In  the  first  phase  of  the  analysis,  the  lULS  tool-set  was  assessed  for  applicability  to  the  PARCS  hardware 
obsolescence  problem.  Following  a  streamlined  model  of  the  lULS  wrapper  development  process,  a  top- 
level  assessment  of  the  PARCS  hardware  obsolescence  problem  identified  emulation  as  a  promising 
wrapper  approach.  Unique  problems,  posed  by  PARCS  from  an  emulation  perspective  were  assessed. 
Section  6.1  and  subsections  present  this  portion  of  the  domain  analysis. 

In  parallel  with  the  assessment  of  PARCS  emulation  problems,  a  second  phase  of  the  analysis  dealt  with 
the  cost  effectiveness  of  an  incremental  upgrade  of  PARCS.  Verifying  the  cost  effectiveness  of  an 
incremental  upgrade  approach  is  a  critical  element  of  the  lULS  wrapper  development  process.  The  intent 
of  this  second  phase  was  to  ensure  that  any  expenditure  of  resources  on  PARCS  would  result  in  an  asset, 
which  is  an  integral  element  of  our  national  defense  system  well  into  the  21®’  century.  In  support  of  this 
analysis  reference  materials  were  analyzed  to  determine  the  overall  status  and  complexity  of  PARCS.  This 
portion  of  the  analysis  was  intended  to  ensure  that  all  problems  facing  PARCS  including  the 
aforementioned  hardware  obsolescence  issue,  were  addressed.  In  addition,  USAF  plans  regarding  future 
upgrades  of  the  Early  Warning  System  (EWS),  were  assessed  to  determine  the  value  of  upgrading 
PARCS.  Both  NMD  resources  and  Radar  Architecture  Migration  Program  resources  were  used  for  this 
purpose.  The  intent  here  was  to  ensure  that  the  PARCS  asset  remains  a  critical  element  of  our  national 
defense  plans.  The  results  of  this  portion  of  the  analysis  are  presented  in  Section  6.2  and  subsections.  As 
described,  this  phase  disclosed  that  PARCS  faces  many  problems  beyond  hardware  obsolescence. 
These  additional  problems  altered  the  recommended  course  of  action.  Briefly  the  analysis  of  Section  6.2 
brings  into  question  the  efficacy  of  expending  additional  resources  on  PARCS.  More  importantly,  the 
detailed  cost  effectiveness  analysis  indicates  that  the  only  viable  approach  to  PARCS  upgrade  is  to 
leverage  the  on-going  activities  required  to  upgrade  the  Early  Warning  Radar  (EWR)  infrastructure  to 
satisfy  National  Missile  Defense  requirements.  If  PARCS  is  to  be  maintained  as  part  of  our  21®’ century 
defense  structure,  it  must  leverage  the  investment  being  made  in  the  EWR  infrastructure. 

The  final  phase  of  the  analysis  was  performed  under  lEIST  funding  and  is  summarized  herein.  In  this 
phase  lEIST  scenarios  were  developed.  Every  effort  was  made  to  include  PARCS  derived  information  in 
these  scenarios.  Results  are  presented  in  Section  6.3.  In  summary,  the  results  are  that  PARCS  offers  no 
benefit  to  any  of  the  lEIST  scenarios  and  will  not  be  included  in  the  lEIST  program. 
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6.1  lULS  Tool-set  Applicability  to  PARCS  Hardware  Obsolescence 

Unique  aspects  of  the  PARCS  system  from  an  emulation  point  of  view  were  assessed.  These  included: 
Symmetrical  Multi-Processing  (SMP)  impacts  including  cache  coherency  with  shared  memory  and  I/O 
problems  specific  to  the  radar  sensor;  Instruction  Set  issues;  Basic  Operating  System  (BOS)  issue;  and 
Tactical  Operating  System  (TOS)  issues. 

6.1.1  SMP  Issues 

The  PARCS  Central  Logic  and  Control  (CLC)  segment,  in  conjunction  with  TOS,  is  a  Symmetrical  Multi¬ 
processing  (SMP)  system.  This  would  require  the  replacement  of  each  Processor  Unit  (PU)  with  an 
equivalent  COTS  processor  (recommend  the  PowerPC)  in  order  to  retain  the  SMP  characteristics  of  the 
system.  While  a  single  COTS  processor  might  exceed  the  entire  CLC  in  raw  (emulated)  performance,  it 
probably  can  not  service  a  large  number  of  concurrent  real-time  events  and  still  meet  latency  requirements. 
Separate  COTS  processors  will  also  help  preserve  any  fault-tolerant  features  of  the  CLC  system. 

Each  PU  has  a  Harvard  architecture  with  separate  memory  spaces  for  instructions  (Program  Store  (PS)) 
and  operands  (Variable  Store  (VS)),  and  all  the  PUs  share  the  respective  spaces  with  each  other.  The 
instruction  space  can  not  be  written  under  program  control  and  therefore  the  instruction  space  can  be 
emulated  locally  on  each  of  the  COTS  processors,  thereby  improving  performance. 

The  PU  supports  a  Duplicate  Mode  that  allows  the  PU  to  try  and  fetch  the  same  instruction  simultaneously 
from  two  Program  Store  (PS)  groups.  With  the  instructions  stored  locally  on  the  COTS  processor,  this 
feature  is  not  needed  and  the  supporting  Duplicate  Mode  instructions  can  be  NOPped. 

The  Variable  Store  (VS)  is  read  and  written  by  all  the  PUs  and  will  require  that  a  cache  coherency  protocol 
be  enforced  for  these  accesses.  The  latest  generation  PowerPC  G4  processor  supports  a  MERSI 
(Modified,  Exclusive,  Reserved,  Shared,  Invalid)  coherency  protocol.  MERSI  assists  in  the  single  writer, 
multiple  reader  cache  coherency  problems.  However,  for  multiple  writers,  software  protocols  need  to  be 
enforced.  These  are  addressed  by  the  Iwarx  and  stwcx  instructions. 

The  Iwarx  instruction  sets  the  RESERVED  bit,  loads  the  location  specified  by  the  effective  address  (EA), 
creates  a  reservation  on  the  local  processor  and  communicates  the  reservation  to  the  other  processors.  If 
another  processor  updates  the  specified  EA  before  the  local  processor  executes  a  stwcx,  the 
RESERVATION  bit  will  be  cleared. 

The  stwcx  instruction  attempts  to  write  the  specified  EA.  If  the  RESERVATION  bit  is  set,  the  instruction 
performs  the  write,  clears  the  RESERVATION  bit,  and  sets  CR0[EQ].  If  the  RESERVATION  bit  is 
cleared,  the  write  is  not  performed  and  CR0[EQ]  is  cleared.  So  while  the  hardware  does  not  guarantee 
atomicity,  it  actively  reports  when  it  fails. 

The  hardware  only  supports  one  reservation  request.  Multiple  Iwarx  instructions  without  matching  stwcx 
instructions  simply  remove  the  reservation  at  the  previous  EA  with  the  reservation  at  the  new  EA.  Also,  in 
a  multi-tasking  environment,  the  Iwarx  /  stwcx.  pair  need  to  be  protected  with  a  critical  section  that  locks 
out  external  interrupts. 

The  SAFEGUARD  machine  has  a  similar  mechanism  with  the  Fetch  and  Bias  Negative  (FBN),  Double 
Fetch  and  Bias  Negative  (DFBN),  and  Double  Conditional  Store  (DCSB).  Instead  of  a  global 
RESERVATION  bit,  the  reservation  bits  are  part  of  the  data  at  the  EA. 

The  FBN  and  DFBN  instructions  perform  similarly  to  Iwarx  except  the  two  most  significant  bits  of  the  evenly 
addressed  EA  are  set  to  ones.  These  instructions  do  not  update  the  parity  associated  with  the  EA.  If 
some  other  instruction  updates  the  EA  prior  to  the  FBN  /  DFBN  instructions  and  the  first  two  bits  are  not  00 
or  11,  then  an  even  parity  condition  is  created  when  the  FBN  /  DFBN  is  executed  (causing  a  parity 
interrupt). 

The  DCSB  instruction  performs  similarly  to  the  stwcx  instruction  except  that  it  checks  the  two  bits  of  the 
evenly  addressed  EA.  If  the  bits  are  both  0,  then  the  store  occurs  otherwise  the  store  fails  and  an 
interrupt  is  generated. 
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6.1.2  Instruction  Set  Issues 

The  PU  floating  point  format  is  a  32  bit,  signed  magnitude,  biased  exponent,  much  like  the  IEEE-754 
formats.  The  IEEE-754  64  bit  double  precision  format  will  easily  contain  the  PU  format,  allowing  floating 
point  operations  to  be  performed  by  the  COTS  hardware,  with  the  emulation  software  performing 
translation  between  the  formats  and  detecting  PU  floating  point  underflow  and  overflow  conditions. 

The  PU  provides  Store  Lockout  functions  for  the  VS  that  prevent  the  PU  from  writing  to  designated  areas 
of  the  VS  and  for  generating  an  interrupt  if  such  an  access  is  attempted.  This  feature  can  be  emulated  by 
using  the  hardware  paging  mechanisms  of  the  COTS  processor. 

6.1 .3  Basic  Operating  System  (BOS)  Issues 

The  primary  purpose  of  BOS  is  to  provide  a  debugging  environment  for  tactical  software  integration.  BOS 
is  not  an  operating  system  per  se,  but  a  set  of  utilities  that  allow  the  loading,  debugging,  and  integration  of 
the  tactical  software  with  TOS.  In  the  controlled  environment  of  the  TRW  emulator  and  associated 
VIEWstation  support  tools,  the  need  for  BOS  would  be  greatly  diminished. 

The  parts  of  BOS  that  would  be  supplanted  by  the  emulator  /  VIEWstation  would  be  the  modules  Main 
Control,  Loader,  I/O  Manager,  Man  Machine,  Debug,  and  Utility  Programs. 

Darts,  Error  Control,  and  Overlay  Manager  would  be  retained  to  support  TOS.  These  modules  interface 
with  both  TOS  and  CLC  Control  and  bridge  between  them. 

6.1.4  Tactical  Operating  System  (TOS)  Issues 

The  Tactical  Operating  System  provides  the  real-time  multi-processor  environment  for  the  tactical 
software.  TOS,  however  is  not  a  pre-emptive  multi-tasking  OS.  Threads  are  entered  and  run  to 
completion,  at  which  time  the  processor  looks  for  a  new  thread  to  run.  The  multi-tasking  in  the  system 
comes  from  having  multiple  processors,  the  more  processors,  the  more  threads  that  execute  concurrently. 
The  Fetch  and  Bias  Negative  and  Double  Conditional  Store  instructions  provide  the  basis  of  the  mutual 
exclusion  that  allows  the  processors  to  safely  locate  and  run  threads  without  interfering  with  one  another. 

The  current  lULS  emulator  makes  use  of  Wind  River’s  VxWorks  both  as  the  real  time  environment  and  the 
development  environment.  VxWorks  also  provides  SMP  capabilities  with  the  VxMP  package.  Parts  of  TOS 
(and  BOS)  can  make  use  of  VxWorks  features,  especially  the  SMP  semaphores,  for  emulating  the  Fetch 
and  Bias  Negative  and  Double  Conditional  Store  instructions. 

The  scheduling  features  of  TOS  have  no  direct  counterparts  in  any  COTS  OS,  and  so  while  it  desirable 
that  some  parts  of  TOS  be  converted  to  make  use  of  the  scheduling  features  of  a  COTS  OS,  it  is  unlikely 
that  TOS  can  be  replaced  one-to-one  with  COTS  OS. 

6.1.5  Conclusions  Regarding  lULS  Emulation  of  PARCS 

Application  of  the  lULS  emulation  tool  to  the  PARCS  domain  is  a  feasible  approach  to  addressing 
hardware  obsolescence.  The  end  product  of  an  emulation  effort  would  be  the  current  PARCS  CLC  object 
code  operating  in  a  new  COTS  based  (PowerPC)  hardware  architecture.  Any  deficiencies  regarding  the 
robustness,  maintainability  and  upgradeability  of  the  PARCS  software  (see  section  3.2)  would  not  be 
redressed  by  this  approach.  Tasks  involved  in  emulating  the  PARCS  CLC  would  include:  Adaptation  of  the 
lULS  1750A  emulator  to  the  SNX360  Instruction  Set  Architecture  (ISA);  Validation  of  the  adapted  emulator. 
Development  and  validation  of  a  set  of  hardware  device  driver  emulations;  Replacement  or  conversion  of 
the  BOS  and  TOS;  Complete  validation  of  emulated  PARCS  functionality.  Although  detailed  cost  estimates 
were  not  in  the  scope  of  this  study,  it  is  obvious  that  any  meaningful  effort  in  this  area  is  well  beyond  the 
resources  available  under  lEIST  funding. 

6.2  PARCS  System  Assessment 

An  integral  element  of  the  lULS  Wrapper  Development  Process  is  execution  of  a  cost  effectiveness 
analysis  of  the  proposed  incremental  upgrade.  In  support  of  this,  a  system  assessment  of  PARCS  was 
performed.  In  this  phase  of  the  analysis,  PARCS  documentation  was  reviewed  with  an  eye  toward 
robustness,  maintainability  and  expandability  of  the  system  software.  The  viability  of  PARCS  as  a  node  in 
the  National  Missile  Defense  (NMD)  infrastructure  and  an  element  in  the  Radar  Architecture  Migration 
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Program  (RAMP)  was  assessed.  Approaches  to  upgrading  PARCS  using  the  lULS  tooi-set,  to 
incrementaiiy  integrate  PARCS  into  RAMP,  were  aiso  expiored.  The  resuits  of  this  portion  of  the  anaiysis 
are  presented  in  the  foiiowing  subsections. 

Section  6.2.1  deais  with  the  robustness  of  the  PARCS  system.  Upon  review,  it  was  discovered  that 
numerous  issues,  over  and  above  hardware  obsoiescence,  face  PARCS.  The  software  is  unmaintainabie 
and  needs  to  be  re-written  and/or  the  system  needs  to  be  re-architected.  These  discoveries  obviate  the 
initiai  indication  that  emuiation  is  the  preferred  methodoiogy.  The  preferred  approach  to  PARCS,  assuming 
sufficient  need  exist  to  justify  the  requisite  funding,  is  to  integrate  PARCS  into  the  Radar  Architecture 
Migration  Program  (RAMP). 

Section  6.2.2  presents  a  top-ievei  description  of  the  BMEWS/PAVE  PAWS  and  COBRA  DANE  systems. 
The  materiais  in  this  section  are  taken  from  the  RAMP  study  and  inciude  discussion  of  using 
BMEWS/PAVE  PAWS  and/or  COBRA  DANE  as  baseiines  in  deveiopment  of  the  Upgraded  Eariy  Warning 
Radar  System  (UEWR).  Section  6.2.3  discusses  the  RAMP  process  and  provides  insight  into  the 
recommended  UEWR  architecture.  It  aiso  discusses  efforts  required  to  inciude  PARCS  in  RAMP  inciuding 
possibie  use  of  lULS  toois  in  the  process.  Section  6.2.4  captures  the  resuits  of  discussions  with  Boeing 
NMD  personnei  regarding  potentiai  contributions  by  an  upgraded  PARCS  to  the  NMD  architecture. 

6.2.1  PARCS  System  Robustness 

Reference  materiais  were  reviewed  to  understand  the  detaiis  of  the  PARCS  system  and  to  gain  an 
understanding  of  the  robustness  of  the  PARCS  software  system.  In  particular,  the  1995  study  of  PARCS 
software  maintainability  was  of  great  use.  It  is  a  very  thorough  study  performed  by  PRC.  It  reported  that: 

•  The  original  maintenance  environment  was  abandoned.  There  exists  no  capability  to  re-compile 
the  system; 

•  As  of  1995  3554  patches  have  been  applied  to  system  representing  95,899  LOC,  777  out  of  1150 
modules  patched  ,  20  or  more  changes  to  33  different  modules,  92  changes  to  one; 

•  Configuration  management  has  been  lost.  A  completely  known  baseline  does  not  exist.  Source 
code  files  do  not  exist,  only  listings  which  may  not  match  executing  code  in  all  instances; 

•  Issue  over  size  of  the  current  satellite  database.  Variable  Store  memory  unit  14  can  only  hold 
8329  objects  -  insufficient  for  current  mission. 

•  The  up-to-date  documentation  for  a  given  CLC  module  is  represented  by  a  collection  of  original 
specifications  or  manuals  for  the  module,  plus  each  and  every  Version  Release  Package  affecting  the 
module  since  its  last  re-compile; 

•  There  is  no  single  updated  version  of  each  document  ...  and  no  assurance  at  this  time  that  the 
collection  of  document  changes  accurately  and  completely  represent  the  operational  code; 

•  There  is  a  wide  variety  in  the  quality  of  patch  documentation; 

•  Currently  four  personnel  (as  of  1995)  are  familiar  with  the  system  -  well  below  minimum.  Only  one 
system  engineer  remains  and  is  expected  to  retire. 

Interestingly,  at  the  time  of  this  report,  hardware  obsolescence  was  not  considered  a  problem. 

The  report  included  numerous  short,  intermediate  and  long-term  recommendations  for  correction  of  the 
observed  deficiencies.  Discussions  with  personnel  at  PARCS  and  at  Peterson  AFB  indicate  that  none  of 
the  recommendations  have  been  executed.  Therefore  the  current  situation  is  that  all  problems  specified  in 
the  1995  report  still  exist,  and  hardware  obsolescence  is  now  a  problem.  This  means  that  to  incrementally 
produce  a  maintainable  system,  all  of  the  short  and  intermediate  terms  recommendations  must  be 
executed  along  with  the  development  and  integration  of  a  new  COTS  based  system  architecture, 
adaptation  of  the  lULS  emulator  to  the  current  PARCS  ISA,  execution  of  the  incremental  upgrade  and 
complete  re-validation  of  the  system. 

This  represents  a  massive  undertaking  and  would  result  in  a  one-of-a-kind  system,  written  in  CENTRAN 
and  executing  functionality,  which  was  developed  in  the  early  seventies.  Clearly,  if  PARCS  is  to  be 
upgraded,  it  must  be  in  accordance  with  the  long-term  recommendation.  To  this  end  an  assessment  of 
inclusion  of  PARCS  in  RAMP  was  executed  as  part  of  the  domain  analysis.  The  following  subsections 
capture  the  results  of  this  analysis. 
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6.2.2  BMEWS/PAVE  PAWS  and  COBRA  DANE  Analyses 

One  approach  to  upgrading  of  PARCS  is  to  buiid  upon  the  commonaiity  between  various  Eariy  Warning 
Radar  (EWR)  sites  to  deveiop  a  new  system  baseiine  for  PARCS.  The  BMEWS/PAVE  PAWS  and 
COBRA  DANE  systems  were  anaiyzed  for  appiicabiiity  to  the  PARCS  probiems.  The  anaiysis  indicated 
that  COBRA  DANE  offered  great  synergy  with  PARCS  and  that  a  PARCS  re-architecture  shouid  reiy 
considerabiy  upon  COBRA  DANE  technoiogy. 

COBRA  DANE’S  primary  mission  is  to  coiiect  inteiiigence  data  on  Soviet  baiiistic  missiie  test  during  the 
exoatmospheric  portion  of  their  trajectories.  This  mission,  caiied  Inteiiigence,  consists  of  coiiection  of 
precise,  muiti-object  radar  measurements  on  Soviet  missiie  weapons  system  deveiopment  and  operationai 
fiights  to  the  Kamchatka  Peninsuia  and  Northern  Pacific  Ocean,  retrograde  iaunches  from  the  Pacific 
Missiie  Fieet  compiex,  and  other  baiiistic  missiie  trajectories  within  the  radar’s  coverage  voiume.  The  data 
coiiected  is  used  to  generate  quick-iook  messages  and  determine  the  missiie  compiex  trajectory  and  type, 
the  type  of  each  object  in  the  compiex  (e.g.,  tank,  re-entry  vehicie,  fragment,  etc.),  the  reiative  position  of 
objects  in  the  compiex,  motion  such  as  spin  rate,  and  the  constructed  image  of  seiected  objects. 

A  coroiiary  mission  is  to  perform  baiiistic  missiie  eariy  warning.  A  surveiiiance  fence  to  detect  baiiistic 
missiies  in  fiight  over  the  COBRA  DANE  azimuth  coverage  is  continuousiy  erected.  This  fence  coverage 
overiaps  that  of  another  radar  system  in  Ciear,  Aiaska  and  can  be  used  either  as  a  backup  sensor  or  to 
provide  enhanced  warning  information.  When  an  earth  impacting  missiie  is  detected,  the  system 
automaticaiiy  issues  iaunch  and  predicted  impact  messages  to  the  Space  Defense  Operations  Center 
whiie  continuing  surveiiiance  for  additionai  missiies.  The  system  reports  object  number,  iaunch  point, 
impact  point,  time  for  aii  earth- impacting  objects,  and  other  eariy  warning  information. 

Space  Surveiiiance  or  Spacetrack,  is  the  system’s  secondary  mission.  COBRA  DANE  augments  the  USAF 
Space  Surveiiiance  system  by  providing  sateiiite  metric  and  signature  data.  To  perform  the  mission, 
COBRA  DANE  maintains  a  cataiog  of  aii  known  Earth  Sateiiite  Vehicies  (ESVs)  which  is  updated  via 
communication  iines  to  Space  Command.  The  system  automaticaiiy  accepts  tasks  for  metric  and  Space 
Object  Identification  (SOI)  signature  from  Space  Command  and  makes  automatic  adjustments  to  the 
Orbitai  Eiement  Set  (OES)  n  the  cataiog  based  on  the  metric  data.  COBRA  DANE  erects  space 
surveiiiance  fences,  which  detect  ESVs  in  a  designated  voiume  of  space.  Any  ESV  detected,  which  does 
not  correiate  with  the  cataiog,  is  automaticaiiy  tracked.  The  data  inciude  detection  of  New  Foreign 
Launches  (NFLs)  within  the  coverage  area. 

Whiie  the  COBRA  DANE  is  not  considered  a  primary  eariy  warning  radar  (EWR)  sensor,  it  provides  the 
basic  capabiiities  of  an  EWR.  COBRA  DANE  was  recentiy  upgraded  and  modernized  via  the  COBRA 
DANE  Modernization  System  (CDSM)  program.  Since  the  current  COBRA  DANE  provides  the  basic  EWR 
capabiiities  and  is  a  reiativeiy  modern  system,  it  is  a  prime  candidate  for  use  in  the  UEWR  architecture. 

The  anaiysis  conducted  indicated  that  the  primary  feature  of  the  CDSM  system  architecture  that  is  most 
appiicabie  to  the  Upgraded  Eariy  Warning  Radar  (UEWR)  architecture  is  the  overaii  distributed  processing 
architecture.  The  particuiar  partitioning  of  processing  functions  across  muitipie  nodes  can  provide  the 
basis  for  a  robust,  expandabie  architecture  for  the  UEWR.  The  processors  for  each  type  of  processing 
node  can  be  seiected  /  sized  to  meet  the  specific  needs  of  the  function  performed  by  the  node  independent 
of  the  other  nodes.  Additionaiiy  each  node  type  can  be  upgraded  individuaiiy  without  impacting  the  other 
nodes.  Though  the  overaii  system  architecture  is  a  strong  candidate  for  reuse  in  the  UEWR,  the  specific 
hardware  components  used  to  impiement  the  CDSM  system  architecture  are  not  candidates  for  reuse. 
Ideaiiy,  use  of  the  current  CDSM  hardware  and  COTS  components  wouid  provide  for  the  ieast  software 
breakage  possibie.  However,  by  retaining  the  same  basic  overaii  CDSM  distributed  processing 
architecture,  the  breakage  to  the  CDSM  software  couid  be  reduced  as  the  primary  effort  wouid  be  porting 
of  the  software  to  the  new  processing  equipment.  Significant  changes  to  the  overaii  system  architecture 
wouid  resuit  in  potentiaiiy  much  iarger  software  breakage.  The  anaiysis  inciuded  a  detaiied  anaiysis  of  the 
CDSM  software  and  its  potentiai  for  reuse  in  impiementation  of  the  UEWR. 
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6.2.3  Radar  Architecture  Migration  Program 

The  Air  Force  has  been  conducting  a  program  for  the  upgrade  of  the  Eariy  Warning  Systems  (EWS) 
known  as  the  Radar  Architecture  Migration  Program  (RAMP).  RAMP  focuses  on  PAVE  PAWS,  Baiiistic 
Missiie  Eariy  Warning  Systems  (SMEWS)  I  &III  and  COBRA  DANE.  RAMP  does  not  specificaiiy  address 
PARCS,  however,  the  methodoiogy  used  in  RAMP  is  an  effective  tooi  for  anaiyzing  hardware  and  software 
upgrade  strategies,  and  the  system  architecture  that  wiii  resuit  from  RAMP  provides  the  optimum  basis  for 
deveioping  a  new  PARCS  system.  Portions  of  RAMP  wiii  be  directiy  appiicabie  to  PARCS  whiie  other 
PARCS  unique  functionaiity  wiii  be  encapsuiated  into  objects  designed  for  compatibiiity  with  the  RAMP 
architecture. 

The  overaii  goais  of  RAMP  are  to  reuse  existing  iegacy  radar  systems  software  and  to  provide  a  common 
architecture  to  assure  future  interoperabiiity  and  affordabie  enhancements.  lULS  techniques  offer 
approaches  for  retaining  the  functionaiity  of  PARCS  and  for  assuring  interoperabiiity  with  the  RAM 
architecture.  The  main  processing  eiement  of  the  PARCS  system  is  a  symmetric  muiti-processing  set  of 
embedded  computers  caiied  the  Centrai  Logic  and  Controi  processors.  These  processors  are  identicai 
Flarvard  architecture  machines  (separate  program  and  data  store  memories)  that  each  executes  a 
scheduied,  non-interruptibie  processing  thread  in  paraiiei  with  the  other  CLC  processors.  These  threads 
are  obtained  from  a  common  process  queue  and  are  scheduied  by  a  distributed  Tacticai  Operating  System 
(TOS). 

The  lULS  tooiset  can  be  used  to  emuiate  this  SMP  architecture  through  the  use  of  a  muiti-processor 
PowerPC  singie  board  computer  wNch  is  itseif  capabie  of  symmetric  muiti-processing.  The  foiiowing 
figure  iiiustrates  the  configuration  of  a  quad  PowerPC  singie  board  computer,  each  of  which  is  configured 
with  an  lULS  emuiator  CLC  Duai  Instruction  Set  Computer  (DISC)  emulator  executing  on  it.  The  lULS 
emulator  CLC  DISC  would  execute  not  only  the  legacy  CLC  processing  threads,  but  the  underlying  TOS 
binary  code  as  well.  I/O  mapping  emulation  software  would  interface  to  a  new  set  of  peripherals  (disks, 
tapes,  printers,  etc.),  user  display  consoles  (X-Windows  UNIX  workstations  or  WindowsNT  PCs),  and  to 
VME  based  radar  sensor  I/O  interfaces. 


Figure  55.  lULS  Emulation  of  PARCS  SMP  Architecture 
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Under  RAM,  component-based  modeling  is  used  to  define  the  interfaces  between  the  various  components 
that  make  up  the  radar  systems  and  then  integrating  existing  components  to  the  maximum  extent  possible. 
The  goal  is  to  find  a  large  number  of  existing  components  that  can  be  inserted  into  a  common  architecture 
under  a  set  of  common  APIs.  The  approach  for  integrating  PARCS  into  RAM  requires  developing  an 
approach  for  re-using  existing  components  of  PARCS.  To  put  it  another  way,  how  can  PARCS 
functionality  be  wrapped  to  conform  to  the  RAM  APIs. 

Two  approaches  for  this  integration  suggest  themselves  from  the  architecture  of  the  PARCS  symmetric 
multi-processing  (SMP)  architecture.  The  first  would  be  integration  at  the  input/output  (10)  layers  of  the 
architecture,  essentially  keeping  all  of  the  PARCS  data  processing  intact  and  operating  as  a  unified  whole 
within  the  confines  of  the  lULS  emulation  of  the  Central  Logic  and  Control  (CLC)  processors  embedded  in 
the  PARCS  system.  The  second  approach  would  be  the  interfacing  of  individual  processing  threads  within 
the  CLC  to  other  reusable  components  that  have  been  or  will  be  developed  for  other  RAM  applications. 

It  should  be  noted  that  these  two  approaches  are  not  mutually  exclusive.  That  is,  the  bulk  of  the  PARCS 
functionality  could  be  integrated  into  the  RAM  architecture  with  some  of  the  internal  process  threads 
replaced  by  reusable  components  from  other  systems  encompassed  by  RAM.  The  10  wrapped  approach 
lends  itself  to  fairly  easy  segregation  of  PARCS  processing  algorithms  from  10  presentation  to  the  user. 
This  would  make  its  implementation  fairly  straightforward  with  minimal  knowledge  of  the  legacy  application 
code  required  and  thereby  lowering  the  technical  risk.  On  the  other  hand,  the  integration  with  RAM  would 
be  at  a  fairly  coarse  level  with  little  benefit  from  RAM  reusable  components.  The  second  approach 
requires  more  domain  knowledge  of  the  PARCS  applications  code  and  more  careful  design  of  the 
wrappers  to  the  lULS  emulator  execution  thunks.  This  increases  the  technical  risk  but  brings  with  it  the 
potential  for  greater  use  of  RAM  reusable  components. 

The  lULS  emulator  capability  of  “thunking”  would  provide  the  “glue”  needed  to  interface  the  legacy 
software  with  the  new  UEWR  interfaces  and  to  disable  sections  of  the  legacy  code  that  have  been 
replaced  with  the  off  the  shelf  components.  Both  of  these  processes  could  occur  incrementally.  Figure  52 
shows  how  lULS  emulator  “thunks”  could  be  used  incorporate  PARCS  legacy  code  into  the  RAM  Technical 
Reference  Architecture  (TRM)  COE  compliant  architecture. 
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Figure  56.  lULS  Emulator  and  RAM  TRM 

The  process  of  integrating  PARCS  functionality  into  the  COE  compliant  RAM  architecture  could  proceed  in 
phases. 

In  the  first  phase,  the  PARCS  legacy  code  (both  applications  and  operating  system  code)  is  treated  as  a 
black  box  that  executes  unmodified  within  the  lULS  emulator  on  new  COTS  hardware.  There  are  a  minimal 
number  of  thunks  implemented  to  allow  the  mapping  of  the  legacy  peripheral  hardware  onto  new  COTS 
peripheral  hardware. 

The  second  phase  integrates  PARCS  legacy  code  to  the  external  world  via  COE  compliant  mechanisms.  In 
this  phase  the  legacy  code  is  still  treated  as  a  black  box  component,  but  the  COE  external  mechanisms 
are  implemented  using  thunks  and  COE  compliant  wrappers.  In  this  phase  the  basic  Message  Oriented 
Middleware  (MOM)  architecture  and  interfaces  are  implemented.  These  interfaces  include  those  with  the 
COTS  OS  and  the  inter-process  communications  between  COE  components.  The  COE  wrappers  conform 
to  the  COE  established  interfaces  and,  in  conjunction  with  the  thunks,  move  data  to/from  the  legacy  code 
from/to  the  external  interfaces. 

In  the  third  phase,  portions  of  the  legacy  applications  code  threads  are  replaced  with  reusable  COE 
compliant  software  components.  The  legacy  code  is  still  treated  as  a  black  box,  but  the  COE  components 
are  treated  as  white  box  components.  The  COE  components  along  with  the  COE  wrappers  and  thunks  for 
COE  capability  that  is  to  be  retained  within  the  legacy  code  allow  data  to  be  moved  into/out  of  the  legacy 
applications  threads.  Thunks  are  also  used  to  disable  portions  of  specific  legacy  applications  threads, 
which  are  then  replaced  with  reusable  COE  components.  As  an  example,  the  ITW/AA  messages,  which 
are  the  Ballistic  Missile  Warning  Attack  Assessment,  are  already  supported  by  PARCS.  The  other 
messages  could  be  synthesized  from  the  PARCS  trackfile  processing  by  the  insertion  of  thunks  that  then 
communicate  with  the  COE  components  that  transmit  the  data  using  the  ADCCP  protocol  to  the 
appropriate  sites. 

In  the  fourth  phase  the  entire  PARCS  legacy  applications  and  operating  system  code  is  replaced  with  COE 
compliant  components,  eliminating  the  need  for  the  lULS  emulator. 
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Integrating  PARCS  into  the  broader  UEWR  architecture  requires  more  detaiied  anaiysis.  A  preiiminary 
anaiysis  of  this  question  is  summarized  in  the  foiiowing  tabies.  It  should  be  noted  however,  although 
emulation  offers  promise  for  porting  portions  of  the  current  object  code  to  a  new  architecture,  it  does  not 
address  any  of  the  maintainability  issues  cited  in  the  reference  materials.  In  particular,  the  absence  of  a 
source  baseline  for  PARCS  is  not  addressed,  nor  are  issues  associated  with  maintaining  an  obsolete 
CENTRAN  source  language. 


Key  System  Architecture  Features 

Pros  /  Cons 

Processing  Architecture 

•  Symmetrical  Multi-Processor  architecture  allows 
throughput  increase  simply  by  adding  additional 
processors. 

•  The  TOS/BOS  operating  system  architecture 
requires  much  manual  labor  to  break  application 
code  into  runable  threads. 

SAFEGUARD  Processors 

•  Will  be  insupportable  in  very  near  future 

•  Not  Dll  COE  compliant 

•  Not  viable  UEWR  option 

Radar  Controller  /  Signal  Processor 

•  Dated  equipment  which  will  be  become 
insupportable  in  near  future 

•  Difficult  to  add  NMD  processing  requirements 

•  Not  Dll  COE  compliant 

Operator  Interface 

•  Dated  and  insupportable  technology 

•  Not  Dll  COE  compliant 

External  Communication  Devices 

•  Dated  and  insupportable  equipment 

Operating  System 

•  Proprietary  OS  supported  only  on  SAFEGUARD 
Processors 

•  Not  Dll  COE  compliant 

•  Not  viable  option 

Table  13.  PARCS  System  Architecture  Analysis 
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Key  Software  Issues _ Pros  /  Cons 


Support  of  UEWR  and  NMD 

Requirements 

•  Provides  the  Early  Warning  and  Space  Surveillance 
missions  as  is 

•  Operator  Interface  software  modifications  required 

•  Radar  scheduling,  commanding,  and  returns  processing 
modifications  required 

•  Tracking  algorithm  modifications  may  be  required 

•  Object  typing  and  discrimination  modifications  required 

Tasking  Architecture 

•  Basic  tasking  architecture  is  non-standard  and  requires 
much  manual  preparation. 

•  Use  of  overlays  must  be  removed 

•  Porting  to  alternative  OS  will  cause  much  breakage  in 
applications  and  in  preparation  process. 

•  Modifications  to  top  level  architecture  will  be  required 
to  support  NMD  and  migration  to  MOM  or  CORBA 
based  architecture 

Implementation  in  SNX/CENTRAN 

•  No  support  of  SNX/CENTRAN  on  modern  platforms 

•  Reengineering  to  another  language  (e.g.,  Ada)  will 
require  significant  resources 

OS  Dependencies 

•  Port  to  alternative  OS  will  cause  significant  breakage 

TTY  and  Card  Reader  based  operator 
interfaces 

•  Not  Dll  COE  compliant 

•  Use  of  Dll  COE  compliant  approach  will  result  in  high 
breakage  in  operator  interface  software  area 

Management  of  disk  based  data  via  OS 
file  services 

•  Use  of  OS  file  services  reduces  interoperability  and 
flexibility 

•  Use  of  OS  file  services  requires  development  of 
application  specific  access  code 

•  Use  of  OS  file  services  for  persistent  data  provides 
ability  to  tailor  for  performance  considerations 

•  Port  to  alternative  OS  will  cause  breakage  in 
applications. 

Table  14.  PARCS  Software  Architecture  Analysis 


6.2.4  PARCS  and  National  Missile  Defense 

In  February  2000,  a  preliminary  presentation  regarding  the  lULS  PARCS  domain  analysis  was  provided  to 
personnel  at  the  PARCS  site.  The  briefing  indicated  that  it  did  not  appear  that  an  incremental  upgrade  of 
PARCS  was  cost  effective  and  that  it  could  not  be  initiated  under  lEIST  funding.  It  was  suggested  that  the 
possibility  of  including  PARCS  in  the  National  Missile  Defense  (NMD)  infrastructure  should  be  examined.  In 
response  to  this  suggestion,  a  visit  to  Washington  DC,  to  the  Boeing  NMD  project  was  executed.  It  was 
learned  that  PARCS  is  not  presently  included  in  the  NMD  architecture  because  inclusion  of  PARCS  offers 
no  enhancement  in  NMD  system  effectiveness,  which  is  measured  by  the  percentage  of  incoming  missile 
threats,  which  are  killed  by  NMD.  In  terms  of  early  detection  of  in-coming  missile  threats,  PARCS  offers 
no  coverage  which  is  not  provided  by  another  asset  and  PARCS  detection  of  an  incoming  threat  is  not 
sufficiently  timely  to  enable  successful  engagement.  However,  it  is  possible  to  build  a  case  for  integrating 
PARCS  into  the  NMD  architecture.  Although  PARCS  offers  no  increase  in  system  effectiveness,  it  does 
offer  an  interim  improvement  in  the  Kill  Assessment  capability,  until  the  time  the  Final  SBIRS  High  satellite 


75 


is  deployed  (earliest  2008).  Kill  Assessment  is  not  an  NMD  system  requirement  but  is  highly  desired  by 
the  NMD  customer. 

6.3  PARCS  and  lEIST 

During  March  2000  the  status  of  the  PARCS  domain  analysis  was  briefed  to  USSPACECOM  personnel  at 
Peterson  AFB.  They  were  also  told  that  incremental  upgrade  of  PARCS  would  not  be  executed  under 
lEIST  funding.  At  that  time  it  was  hoped  that  PARCS  could  be  included  as  a  node  in  the  Joint  Battlespace 
Infosphere  in  one  or  more  of  the  lEIST  scenarios.  During  the  aforementioned  visit  to  the  Boeing  National 
Missile  Defense  project,  the  potential  for  an  lEIST  NMD  scenario  was  explored.  The  viability  of  including 
the  Perimeter  Attack  Characterization  Radar  System  in  the  NMD  architecture  was  also  discussed.  The 
results  of  the  meeting  were  not  favorable  in  terms  of  identifying  a  candidate  scenario.  The  primary 
objectives  regarding  the  lEIST  scenario  are:  1)  integration  of  legacy  embedded  systems  into  the  Joint 
Battlespace  Infosphere  (JBI),  2)  leveraging  of  lULS  and  related  AFRL  technologies  and  3)  building  upon 
the  foundation  scenario  and  architecture  developed  for  WSOA/QuoTE.  Based  upon  the  information 
exchange  at  the  meeting,  we  did  not  believe  that  we  could  develop  a  credible  NMD  scenario,  which 
satisfies  the  primary  lEIST  objectives.  NMD  execution  timelines  are  limited  to  very  short  duration  (on  the 
orders  of  seconds)  and  extremely  high  system  reliability  because  the  NMD  scenarios  focus  on  weapons  to 
destroy  in-coming  ballistic  missiles  themselves,  and  not  the  launchers  (which  clearly  do  fit  the  lEIST 
CONORS).  The  consensus  was  that  there  is  little  or  no  potential  fit  between  NMD  and  lEIST. 

6.4  PARCS  Summary 

This  lULS  PARCS  study  was  initiated  to  examine  the  feasibility  of  utilizing  the  lULS  toolset  to  incrementally 
upgrade  PARCS  to  alleviate  a  hardware  obsolescence  problem.  The  analysis  indicates  that  this  could  be 
reasonably  accomplished.  However,  part  of  the  lULS  upgrade  process  entails  evaluation  of  the  overall 
cost  effectiveness  of  the  upgrade.  The  results  here  are  not  promising.  Because  of  the  obsolete  and 
unmaintainable  nature  of  the  PARCS  software,  incremental  upgrade  cannot  be  recommended. 

An  alternate  approach  of  re-architecting  PARCS  under  the  RAMP  program  was  examined.  This  approach 
is  viable  and  might  be  enhanced  using  lULS  tools  to  assist  in  the  process.  We  believe  that  emulation  could 
be  applied  to  develop  an  interim  product,  but  in  the  long-run  maintainability  issues  need  to  be  addressed. 
Also,  as  we  have  indicated  the  selective  use  of  code  translator  technology  should  be  explored  if  a  PARCS 
upgrade  program  is  initiated.  It  is  believed  that  an  lULS  Technology  Demonstration  could  be  constructed 
along  these  lines.  It  is  suggested  that  an  effort  be  undertaken  to  identify  funding  for  this  approach.  A 
starting  point  for  generating  the  need  could  be  the  NMD  interim  Kill  Assessment  capability  afforded  by 
PARCS.  Certainly,  continuation  of  its  current  space  tracking  function  is  an  additional  need  for  PARCS. 
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7  lULS  CV-22  Transition 

The  objective  of  this  on-going  technoiogy  deveiopment  is  to  demonstrate,  extend,  and  transition  lULS 
tooiset  technoiogy  to  the  Air  Force  speciai  operations  variant  of  the  V-22,  denoted  the  CV-22.  The 
program  began  in  Juiy  2000.  The  current  CV-22  system  of  the  Speciai  Operations  Command  (SOCOM) 
inciudes  an  Advanced  AYK-14  mission  computer.  Aithough  not  yet  in  fuii-  scaie  production,  the  CV-22 
faces  probiems  inciuding  hardware  obsoiescence  and  iimited  growth  potentiai.  The  CV-22  program 
roadmap  (foiiowing  figure)  identifies  a  major  upgrade,  Biock  20,  which  wiii  commence  EMD  in  FY2002. 
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Figure  57.  CV-22  Program  Roadmap 

One  of  the  key  components  of  Biock  20  is  the  Common  Avionics  Architecture  for  Penetration  (CAAP), 
starting  in  the  in  the  2001  time  frame.  CAAP  has  three  main  objectives:  1)  Reduce  enemy  abiiity  to  detect 
incoming  SOF  penetration  aircraft;  2)  Fuse  off-board  and  on-board  data  for  enhanced  situational 
awareness;  and  3)  Create  a  common  processing  architecture  for  all  future  SOF  aircraft.  Features  of  the 
CAAP  program  are  illustrated  in  the  following  figure.  The  CV-22  will  require  significant  additional 
processing  resources  to  accommodate  requirements  for  new  and  expanded  capabilities  for  terrain 
following  and  situation  awareness  as  identified  for  CAAP.  The  CV-22  program  is  supporting  a  detailed 
trade  study  to  identify  potential  technologies  for  meeting  these  processor  requirements. 
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Figure  58.  CAAP  Program  Elements 

In  this  effort,  lULS  technology  for  automatic  generation  of  wrapper  software  is  being  applied  to  investigate 
migration  of  the  CV-22  to  a  Commercial  Off-The-Shelf  processor  (PowerPC)  and  incorporation  of 
prototype  CAAP  functionality.  This  effort  includes  development  of  a  lab-quality  COTS  Replacement  Box 
(CRB)  that  incorporates  significant  and  applicable  components  of  CV-22  mission  processing  functionality, 
and  prototype  CAAP  functions  for  terrain  following.  The  following  figure  depicts  the  CV-22  processor 
architecture  and  CRB  migration.  Prototype  CAAP  processing  to  be  "wrapped"  into  the  mission  processor 
was  selected  from  candidates  including  blended  radar  processing,  data  fusion,  and  enhanced  situation 
awareness.  The  Quiet  Knight  ATD,  a  precursor  to  CAAP,  has  demonstrated  the  feasibility  and 
effectiveness  of  CAAP  technology,  and  provides  a  source  of  prototype  CAAP  software. 
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Figure  59.  CV-22  Processor  Architecture  and  CRB  Migration 

The  effort  supports  key  avionics  upgrade  trade  studies  being  considered  by  the  CV-22  for  transition  to  an 
open  system  architecture  by  providing  performance  benchmarks  and  risk  reduction.  The  effort  includes 
both  re-host  activities  to  transition  to  the  COTS  processor,  and  incorporation  of  prototype  CAAP 
functionality.  The  lULS  toolset  developed  under  the  lULS  program  is  being  applied  to  support  automatic 
generation  of  wrapper  software  for  the  new  functionality. 
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This  lULS  TD  program  has  significant  potentiai  carry-forward  technoiogy  for  the  CV-22  program.  First,  it 
wiii  provide  essentiai  data  supporting  the  CV-22  open  system  trade  study  by  wrapping  and  rehosting  JASS 
software  to  an  open  system-based  CRB.  Second,  it  wiii  verify  performance,  generate  benchmark  data, 
and  estabiish  CRB  growth  potentiai  to  support  CV-22  requirements  by  conducting  CV-22  integration  tests 
to  vaiidate  migration  to  a  COTS  processor.  Finaiiy,  it  wiii  provide  advanced  risk  reduction  for  SOCOM  / 
CV-22  and  demonstrate  transitionabiiity  of  the  iULS  technoiogy  by  "wrapping"  prototype  CAAP 
functionaiity. 

The  CV-22  iULS  effort  represents  a  variation  of  the  "rehost"  wrapper  approach.  This  technique  ieverages 
extensive  software  deveiopment  activity  by  the  V-22  program  in  generation  of  the  JASS  Ada  83  baseiine, 
and  faciiitates  potentiai  re-use  of  Quiet  Knight  and  other  potentiai  CAAP  functionaiity.  The  rehost  effort 
provides  a  migration  of  the  OFP  from  the  iegacy  advanced  AYK/14  processor  to  an  open  Boid  Stroke 
configuration,  in  the  CV-22  case,  the  iegacy  advanced  AYK/14  processor  does  not  have  the  growth 
potentiai  to  meet  the  demanding  processing  requirements  for  CAAP.  Wrappers  are  being  constructed 
around  the  re-hosted  software,  and  around  the  prototype  CAAP  software.  The  foiiowing  figure  shows  the 
iegacy  system  and  the  wrapped  demonstration  system. 


Figure  60.  Legacy  and  Demonstration  System  Architecture 


The  Boeing  Company  is  pursuing  a  very  simiiar  Yehost'  approach  on  the  F-15E  production  program,  in  that 
case,  F-15E  fiight  software  is  being  rehosted  from  the  iegacy  Ada  83  software  operating  on  the  VFiSiC 
Centrai  Computer  to  the  Boid  Stroke  environment  using  Ada  95.  This  approach  resuited  from  a 
comprehensive  trade  study,  which  considered  many  different  options  for  F-15E  integration  within  Boid 
Stroke  environment.  The  foiiowing  figure  shows  the  options  that  were  considered  in  the  study.  Option  4  - 
Utiiize  infrastructure  Services  -  was  seiected  for  impiementation.  it  provides  rehosted  Ada  code  on  the 
PowerPC  and  utiiizes  iow-ievei  Boid  Stroke  infrastructure  services.  Considerations  that  ied  to  the  seiection 
were:  1)  Options  4  and  5  wiii  minimize  the  cost  of  future  SW  enhancements  and  maintenance,  by  making  it 
easier  to  distribute  the  code  and  muiti-thread  the  appiication;  2)  Options  3,  4  and  5  wiii  minimize  the  cost  of 
future  H/W  upgrades  by  insuiating  the  user  appiication  from  the  underiying  FiW  and  operating  system;  and 
3)  Options  3,4,  5  provide  a  path  for  easier  migration  to  a  iong  term  object  oriented  soiution.  The  iULS  CV- 
22  program  is  abie  to  directiy  utiiize  Ada  bindings  to  the  Boid  Stroke  infrastructure  that  were  deveioped  as 
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a  direct  result  of  this  option.  In  addition,  F-15E  lessons  learned  on  development  of  the  new  executive,  use 
of  the  infrastructure,  and  support  for  global  I/O  databases  are  being  applied  to  the  VC-22  TD  program. 
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Figure  61 .  F-1 5E  Options  for  Rehost 


7.1  Foundation  Programs 

This  element  of  the  Incremental  Upgrade  of  Legacy  Systems  demonstration  program  is  based  upon  the 
adaptation  of  the  V-22  Osprey’s  JASS  Avionics  Operational  Flight  Program  (OFP).  JASS  is  the  embedded 
avionics  OFP  that  was  designed  and  targeted  for  a  custom  built  Advanced  Mission  Computer  (AMC) 
written  entirely  in  the  Ada-83  programming  language.  Components  of  the  embedded  operating  system 
components,  provided  by  the  computer  manufacturer  were  written  in  Ada  as  well. 

The  development  of  the  AMC  and  the  operating  system  components  were  funded  by  the  V-22  program 
and  the  LAMPS  Update  program  by  Loral  and  Computing  Devices  International  (currently  known  as 
General  Dynamics  Information  Systems).  The  JASS  software  application  was  designed  as  a  single 
Configuration  Item  (Cl)  integrating  13  functional  areas.  These  areas  include  Aircraft  Subsystems,  Blade 
Fold  /Wing  Stow,  Central  Integrated  Checkout,  Communications  and  Identification,  Controls  and  Displays, 
Electronic  Warfare,  Executive,  Flight  Director  and  Guidance,  Mission  Management,  Multifunction  Remote 
Terminal  Input  Output,  Navigation,  and  Tactical  Sensors.  The  runtime  system  is  based  upon  the  Ada  run¬ 
time  system  that  is  included  with  the  Rational  Software  VADS  Ada  Cross-Development  System.  The 
runtime  component  provides  a  multitask,  priority  based,  periodic  operating  system.  Inter-task 
communication  is  achieved  by  the  use  of  mailboxes,  allowing  data  and  messages  to  be  passed  and 
executed  at  the  appropriate  task  priority. 

This  element  of  the  lULS  demonstration  integrates  portions  of  the  JASS  application  software  with  CORBA- 
compliant  ORB  software  and  a  run-time  system  that  is  commercially  available.  The  integration  of  these 
software  components  then  provides  the  foundation  for  the  inclusion  of  additional  avionics  functionality  that 
can  be  integrated  via  an  open  system  interface.  The  demonstration  will  also  address  the  issues  that 
involve  the  use  of  multi-language  implementations  where  the  host  application  and  the  ORB  interface  will 
utilize  Ada  and  C-i-i-.  Additional  multi-language  considerations  will  be  determined  during  the  assessment  of 
additional  avionics  functionality. 

An  early  task  in  the  transition  effort  was  a  trade  to  identify  the  JASS  Functional  Areas  with  the  highest 
relevance  to  CAAP.  These  are  the  best  candidates  for  rehost  to  the  Bold  Stroke  Architecture  under  the 
lULS  Transition  effort.  The  following  figure  shows  the  initial  component  selection.  It  will  be  confirmed 
through  additional  system  analysis  before  the  demonstration  content  is  finalized. 
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Figure  62.  Tech  Demo  Components  Selected  for  CAAP  Relevancy  (Preliminary) 

The  following  figure  illustrates  the  architectural  organization  of  the  software  that  will  result  from  the  CV-22 
TD  program. 
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Figure  63.  CV-22  Demonstration  Software  Architecture 

7.2  lULS  CV-22  Transition  Benefits 

The  CV-22  lULS  TD  program  provides  extensive  transition  benefits  to  the  CV-22  program.  First,  the  lULS 
TD  program  is  demonstrating  through  execution  of  system  level  tests  that  the  CRB  incorporating  the 
rehosted  /  wrapped  JASS  software  can  successfully  complete  “red-lined”  CV-22  test  procedures.  This 
establishes  the  fidelity  of  the  wrapping,  and  will  provide  a  path  that  can  affordably  migrate  the  JASS  OFP 
from  the  legacy  advanced  AYK/14  to  a  much  more  powerful  COTS  Open  System  CPU.  Moreover,  this 
effort  demonstrates  the  use  of  software  wrappers  to  enable  incorporation  of  prototype  CAAP  functionality. 

This  will  further  demonstrate  the  growth  potential  of  the  COTS  system  and  enable  generation  of  system 
benchmarks  including  spare  capacity.  The  TD  program  represents  a  major  risk  reduction  for  the  CV-22 
program  as  it  looks  to  develop  its  future  end-state  software  and  hardware  architecture  in  preparation  for 
planned  Block  upgrades.  The  benefits  of  the  lULS  CV-22  Transition  are  captured  in  the  following  figure. 
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8  Other  Wrapper  Applications  and  Upgrade  Technology 

This  section  wiii  describe  the  appiication  of  software  wrappers  to  other  embedded  systems  and  appiication 
domains,  and  discuss  reiated  software  technoiogy  that  can  be  appiied  to  the  upgrade  probiem. 

8.1  Other  lULS  Applications 

8.1 .1  Open  Systems  Architecture  Wrappers 

The  iULS  approach  is  currentiy  being  appiied  to  reuse  embedded  software  for  the  AFRL  Weapon  System 
Open  Architecture  (WSOA)  GRAD  Project.  The  objective  of  the  project  is  to  prototype  middieware  and 
appiication  software  to  enabie  a  weapon  piatform  such  an  F-15  and  a  command  and  controi  C2)  piatform 
such  as  an  AWACS  to  exchange  images  and  to  coiiaborativeiy  repian  a  mission  efficientiy  via  a  Link  16 
network.  The  project’s  demonstration  fighter  node  is  F-15E1,  the  same  vehicie  and  processor/OFP  used 
for  the  iULS  OWS  demonstration  described  in  Section  5.  The  OFP  did  not  have  a  JTiDS  processing 
function  to  support  the  project.  A  mature  JTiDS  function  was  avaiiabie  from  the  F-15  production  OFP  that 
supported  the  operation  of  a  Ciass  ii  terminai,  the  Link-16  interface  and  cockpit  dispiay  formats  drivers. 

As  in  the  F-15  OWS  case,  the  reusabie  JTiDS  software  did  not  match  the  host  ianguage  (Ada83  vs.  C-i-i-) 
or  architecture  (hierarchicai  vs.  00).  iULS  methodoiogy  was  used  to  perform  a  brief  FODA  that  indicated 
that  a  wrapper  was  feasibie  and  the  best  way  to  provide  the  F-15  OFP  with  the  JTiDS  functionaiity.  The 
architecture  of  the  OFP  with  wrapped  JTiDS  software  is  very  simiiar  to  the  OWS  wrapper  architecture 
iiiustrated  in  Figure  17.  The  major  differences  are  that  the  JTiDS  components  are  iarger  and  more  seif- 
contained  (the  major  data  interfaces  are  internai  PiMs  between  components),  and  they  are  aii  executed 
oniy  at  a  20Hz  rate.  The  software  is  at  the  “Design  Wrapper”  process  step  at  the  time  of  this  writing. 

in  1998,  the  use  of  iULS  methodoiogy  was  inciuded  in  a  Boeing  (McDonneii  Dougias)  proposai  to  NASA  to 
upgrade  the  Space  Shuttie’s  avionics  system.  The  Shuttie’s  quad-redundant  centrai  computers  have 
obsoiete  processors  and  the  OFPs  are  written  in  a  unique,  costiy  to  maintain  ianguage  caiied  FiAL.  The 
three  approaches  summarized  in  Section  3.1  were  considered  and  variations  were  proposed.  The 
computers  perform  both  mission  and  fiight  criticai  (inner-ioop  fiight  controi)  processing  so  the  iULS  toois 
wouid  have  to  be  extended  and  their  operations  formaiiy  quaiified  for  this  domain  by  Fioneyweii.  This  task 
is  reasonabie  since  Fioneyweii  has  another  speciaiized  tooi  in  this  famiiy  for  fiight  controi  software,  but  it 
wouid  be  out-of-scope  for  the  iULS  project.  Due  to  programmatic  issues  inciuding  cost/scheduie 
constraints,  NASA  has  not  contracted  an  upgrade,  and  a  new  round  of  studies  is  currentiy  in  progress. 

8.1 .2  Wrappers  For  Scientific  Computing 

There  is  a  iarge  body  of  software  written  over  the  past  30  year  that  supports  the  engineering  and  scientific 
community  and  is  now  becoming  obsoiete  in  terms  of  source  and  object  ianguage,  host  system 
dependencies,  and  compatibiiity  with  new  software  systems  inciuding  distributed  processing,  it  is  typicaiiy 
written  in  eariy  versions  of  FORTRAN  running  on  dedicated  mainframes  or  “minis”  for  one  speciaiist  user 
and  is  rareiy  weii  documented. 

The  iULS  project  had  a  technicai  exchange  with  JPL  staff  members  regarding  the  upgrading  and  reuse  of 
their  optics  anaiysis  utiiity  iibrary.  Their  organization  maintains  a  iarge  iibrary  of  simiiar  appiications  and  is 
interesting  in  modernizing  the  software  systems  and  making  them  more  user-friendiy.  They  had  aiready 
proposed  and  manuaiiy  impiemented  wrappers  for  some  appiications,  and  they  were  intrigued  by  the 
automated  anaiysis  and  design  capabiiities  of  iULS.  During  the  technicai  exchange,  it  was  obvious  that  the 
smaii  interface  size  and  uniqueness  of  each  appiication  wouid  make  the  cost  of  anaiysis,  modeiing, 
evaiuation,  and  interface  iibrary-buiiding  with  the  ULS  tooiset  unjustifiabie.  Their  work  can  serve  as  a 
modei  for  upgrading  this  domain  of  software. 

8.1 .3  Wrappers  For  Business  and  Information  System  Applications 

There  is  a  huge  body  of  software  written  over  the  same  period  for  the  business  and  financiai  community 
empioying  a  wide  variety  of  architectures,  ianguages,  APis,  databases,  and  user  interfaces.  The  most 
common  ianguage  is  COBOL,  and  most  common  user  access  is  dumb  terminais  and  point  of  saie/entry 
devices.  The  vision  of  most  of  the  business  worid  is  “e-Business”  that  is  being  impiemented  in  distributed. 
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heterogeneous  processing  and  “Web-like”  user  interfaces.  Upgrading  and  “Web-a-fying  these  systems  is 
currently  a  massive  undertaking  that  uses  wrappers/adapters  to  some  extent. 

The  lULS  team  had  several  technical  exchanges  with  the  Boeing  corporate  data  processing  support  group 
that  is  responsible  for  this  transformation  within  Boeing.  We  concluded  that  the  lULS  toolset  was  too 
specialized  (embedded,  real-time)  for  this  software  domain  although  Honeywell  conceptualized  and 
demonstrated  how  it  could  be  extended  for  business  applications,  languages  (including  C-i-i-  and  Java),  and 
interfaces.  Major  software  and  hardware  manufactures  (Oracle,  Microsoft,  Sun,  IBM,  etc.)  now  provide 
this  upgrade  service  with  a  wrapper  approach  as  one  of  their  techniques. 

There  is  a  growing  body  of  academic  research  in  classifying  software  architectures  (notably  at  Carnegie 
Mellon  University),  and  then  identifying  techniques  for  resolving  software  component  “packaging” 
mismatches  with  wrappers,  bridges,  mediators,  etc.  [see  Reference  3  in  Section  10.1,  Bibliography]. 
Wrappers  are  being  implemented  commercially  for  legacy  data  sources  and  database  systems  (as  in 
IBM’s  Garlic  project,  [18]),  and  for  systems  interaction  (brokers,  agents,  and  protocols  by  Sun). 

00  wrappers  for  DOD  information  systems  were  the  subject  of  an  Institute  for  Defense  Analysis  study  for 
the  Defense  Information  Systems  Agency  in  1996.  This  work  was  described  in  the  report  Legacy  System 
Wrapping  for  DOD  Information  Systems  Modernization  [4].  Several  migration  strategies  and  guidelines 
are  described  including  SQL-to-Ada  bindings  for  wrapping  a  database  management  system.  A  wrapper 
generator,  “Rapper”,  was  developed  for  a  CIA  database  management  system  during  a  study  by  MITRE 
Corporation  that  arrived  at  some  of  the  same  lessons  learned  as  lULS  [14]. 

8.2  Wrappers  and  Software  Reuse 

Since  the  lULS  Project  began  in  1997,  the  software  engineering  discipline  of  reusable  software  has  grown 
and  matured  greatly.  While  the  major  thrust  is  designing  for  reuse  and  “product-line  software 
development”,  much  of  the  methodology  can  also  be  applied  to  software  upgrades:  domain  analysis, 
architectural  patterns  and  modeling,  and  re-engineering  or  refactoring  of  existing  software  for  reuse.  The 
Boeing  Phantom  Works  OSA  group  has  been  a  leader  in  reuse  technology  in  the  real-time  embedded 
object  oriented  software  domain  [23].  There  are  many  technical  papers  and  books,  conferences,  and 
tutorials  that  describe  software  reuse  technology  in  many  software  domains  such  as  those  by  Ivar 
Jacobsen  [8]. 

8.3  Other  Software  Upgrade  Approaches 

Both  DoD  and  the  commercial  world  have  developed  upgrade  techniques  that  are  similar  to  lULS  wrapper 
approaches  and/or  share  some  of  the  same  principles  such  as  model-based  re-engineering. 

The  first  design  activity  of  the  “Rehost  approach”  typically  consists  of  translation  and/or  recompilation  of 
the  legacy  software  so  it  can  be  executed  (re-used)  on  the  upgraded  processor  inside  a  wrapper.  Under 
the  Embedded  Information  System  Re-Engineering  (EISR)  project  for  AFRL,  Lockheed  Martin  is 
developing  an  automation-assisted  JOVIAL-to-C  re-engineering  capability  that  permits  transformation  of 
both  the  software’s  source  language  and  architecture  [12].  Automated  JOVIAL-to-Ada  translation  was 
used  successfully  by  Boeing  to  rehost  the  C-17’s  Mission  Computer  OFP  to  the  COTS  CIP  processors  for 
the  upgrade  described  in  Section  6.6.3  [17].  And  the  list  of  target  processors  supported  by  the  USAF’s 
JOVIAL  toolset  has  grown  to  include  COTS  processors  [http://www.iovial.hill.af.mil1. 

A  variation  of  the  “Hybrid  approach”  employing  a  split  processor  chassis  is  being  used  in  several  upgrades. 
Generally  a  new  chassis  is  designed  with  sections  for  legacy  modules  and  their  backplane,  and  new 
COTS-based  modules  and  their  backplane.  A  backplane  bridge  is  designed  to  link  the  two  sections 
containing  adapter  software;  additional  wrappers  are  developed  for  the  upgraded  applications  on  the  new 
processor  modules.  For  example,  the  new  AV-8B  “OSCAR”  Weapon  Processor  contains  COTS 
processors  on  a  VME  backplane  running  re-engineered  OFPs,  and  a  section  of  legacy  backplane  housing 
reused  weapon  interface  modules  that  have  no  COTS  equivalent  (and  would  be  too  expensive  to  re¬ 
engineer). 
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A  variation  of  software-based  iegacy  “Emuiator  approach”  that  was  successfuliy  demonstrated  on  lULS 
and  other  programs,  is  the  firmware  or  hardware-based  emulator.  For  example,  CPU  Technologies  has 
produced  a  1750  emulator  “system-on-a-chip”  that  is  being  used  to  upgrade  the  F-16’s  radar  processor 
fhttp://www.cputech.com1. 

The  problem  of  inserting  new  and  upgraded  software  into  real-time  software  architectures  in  a  safe  and 
reliable  manner  is  addressed  by  the  Simplex  Architecture  from  the  Software  Engineering  Institute  [22].  It 
provides  for  the  dynamic  alteration  of  active  systems,  as  well  as  fault  tolerance  and  support  for 
heterogeneous  languages  and  processors  in  a  real-time  system.  It  has  been  demonstrated  a  number  of 
times  and  is  well-documented  [http ://www.sei. cmu.edu/simplex1. 

Simplex  is  a  key  element  of  the  Incremental  Software  Evolution  for  Real-Time  Systems  (INSERT)  R&D 
program  that  Lockheed  Martin  is  conducting  for  AFRL.  It  has  produced  a  “COTS-based  solution  for 
building  high-assurance  applications”.  The  “replacement”  applications  are  run  on  top  of  an  INSERT 
middleware  layer  that  insulates  (wraps)  them  from  the  underlying  RTOS  and  processor  hardware,  and 
provides  virtual  memory  partitioning  and  communication  via  asynchronous  messaging.  The  INSERT  system 
has  been  demonstrated  in  a  rehost  of  F-16  AFTI  JOVIAL  weapon  delivery  software  from  a  1750 
processor  to  a  Pentium  processor  [1]. 

8.4  Upgrade  Tools  and  Modeling 

Two  technologies  that  lULS  employs  have  expanded  and  matured  since  lULS  was  proposed:  Model-based 
software  development  and  a  related  area,  auto-code  generation. 

HTC’s  DOME  and  WrapidH  are  the  practical  foundation  for  the  lULS  methodology.  Since  lULS  began,  the 
Unified  Modeling  Language  (UML)  has  become  the  standard  for  object  oriented  software  development,  and 
has  successfully  been  implemented  in  software  development  systems  such  as  Rational’s  Rose 
[http://www.rational.com1.  The  DOME  notation  toolset  includes  a  subset  of  UML  but  WrapidH  was  not 
revised  to  include  it.  UML  is  a  viable  alternative  to  modeling  existing  as  well  as  new  application  software 
and  wrappers,  but  the  model  could  not  be  the  source  for  to  the  lULS  Honeywell  analysis  and  code 
generation  capabilities.  However,  automatic  generation  of  code  from  UML  models  in  several  HOLs  is  the 
goal  of  integrated  tool  vendors  such  as  Rational  [15]. 

Generic  patterns  are  now  commonly  used  for  characterizing  and  designing  software.  The  publication  of 
the  Gamma  patterns  book  [6]  formally  introduced  a  basic  family.  Among  the  most  useful  are  the  Fagade, 
Adapter,  and  Proxy  structural  patterns,  and  the  Mediator  behavioral  pattern.  More  specialized  interface 
patterns  are  especially  valuable  to  describe  wrapper  design  such  as  the  Wrapper  Fagade  [19],  whose 
intent  is  to  “encapsulate  low-level,  stand-alone  functions  with  00  class  interfaces”. 

Another  example  of  a  pattern  application  to  wrapper  design  is  the  interface  between  00  software  and 
entity  or  relational  databases  (RDBs)  that  are  common  in  business  systems.  They  can  be  built  with 
generic  data  interface  components  through  a  data  object  generalization  pattern  [10]  that  is  a  generalization 
of  the  data  conversion  wrapper  components  designed  for  the  F-15  OWS  wrapper. 

Several  code  analysis  tools  were  examined  early  in  the  lULS  project  for  their  usefulness  in  characterizing 
legacy  software  during  domain  analysis  that  may  require  reverse  engineering  if  the  product  is  not  well 
documented.  The  McCabe  toolset  [http://www.mccabe.com],  and  in  particular,  the  “Battlemap”  was  found 
to  be  a  valuable  way  to  visualize  existing  Ada  and  C  software.  An  evaluation  copy  of  the  Xinotech  toolset 
[http://www.xinotech.com]  was  acquired  and  applied  to  some  of  the  legacy  F-15  code  during  the  FODA 
phase.  Since  the  F-15  OFP  was  well  known  and  documented,  the  tool’s  output  did  not  add  much  value. 
However  since  that  time,  both  toolsets  have  been  enhanced  and  bundled  with  other  tools.  Xinotech  is 
promoted  as  a  robust  reengineering  system  and  is  being  used  successfully  on  the  ESIR  project  that  was 
previously  described.  Another  visualization/reverse-engineering  toolset  family  that  software  reuse 
designers  have  found  useful  is  Understand  for  FORTRAN,  Understand  for  Ada,  and  Understand  for  Cfrom 
Scientific  Toolworks  [http://scitools.com1.  This  type  of  analysis  tool  should  be  a  part  of  the  upgrade  SEE 
along  with  DoME  and  WrapidH. 

There  are  a  number  of  ongoing  projects  in  industry  and  academia  in  the  areas  of  tools  and  methodology  for 
software  analysis,  design,  test,  and  cbcumentation  that  could  be  applied  to  the  upgrade  process.  For 
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example,  DARPA/ITO  under  the  Evolutionary  Design  of  Complex  Software  (EDCS)  program  sponsored  the 
Capability  Packaging  for  Avionics  (CPAS)  project  at  Northrop  Grumman  Corporation.  CPAS  integrated 
EDCS  technologies  in  three  areas:  Software  understanding  through  visualization  tools;  incremental 
analysis/test  and  certification  tools;  and  architecture-driven  design  and  composition  tools.  CPAS  has  been 
applied  to  the  B-2  avionics  system  software  in  preparation  for  incremental  enhancement  as  well  as  ongoing 
maintenance  [http ://www. northrop.com/cpas1. 
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9  lULS  Lessons  Learned  and  Conclusion 

This  section  summarizes  some  iessons  iearned  during  the  project  regarding  software  upgrades  using 
wrapper  technoiogy  and  the  iULS  methodoiogy. 

9.1  IULS  Process 

We  found  that  following  the  wrapping  process  described  in  Section  3  does  result  in  a  reasonably  well- 
designed  OFP  for  our  F-15  applications,  and  several  steps  yielded  lessons  learned  or  are  especially 
noteworthy. 

The  most  essential  and  time-consuming  pre-design  step  was  the  characterization  of  the  legacy  software. 
The  older  the  software,  the  less  likely  that  it  has  complete  and/or  accurate  documentation  including 
comprehensive  test  cases.  It  is  vital  that  a  domain  expert  with  tribal  knowledge  of  the  design  and 
operation  be  involved  in  the  documentation  of  the  data  interfaces.  Each  interface  parameter  must  be 
analyzed  and  classified  in  minute  detail  as  illustrated  for  the  F-15  project  in  Section  4.3  and  the  data 
mapping  table  in  Appendix  A.  This  table  was  in  use  until  the  final  code  corrections  were  made  prior  to 
system  integration.  This  task  can  be  done  more  efficiently  with  the  code  parsing  tools  and  re-engineering 
tools  mentioned  earlier. 

The  wrapper  control  flow  and  top-level  architecture  were  relatively  easy  to  design  because  the  wrapped 
parts  were  modular  and  had  straightforward  execution  dependencies.  The  wrapper  designer  has  some 
flexibility  in  this  area,  especially  if  unexecuted  code  and  unused  parameters  can  be  left  in  the  reused  legacy 
code  after  they  are  understood/documented. 

Training  on  the  IULS  toolset  and  the  RePLACE  systems  is  required,  even  for  experienced  software 
designers.  Some  experience  with  model-based  software  development  is  very  helpful.  Those  doing  the 
detailed  wrapper  design  and  integration/test  activities  must  be  skilled  in  the  wrapper  language(s),  and  have 
at  least  a  working  knowledge  of  the  legacy/rehosted  software  language  as  well. 

TRW’s  RePLACE  system  is  relatively  hdependent  of  the  IULS  toolset.  Integrating  the  two  was  out  of 
scope  for  the  current  project.  The  domain  analysis  and  characterization  process  steps  must  be  completed 
no  matter  which  “back  end”  wrapper  design  process  is  employed. 

Although  the  wrapper  approach  has  been  validated  for  upgrades  in  many  software  domains,  the  IULS 
toolset  is  currently  targeted  to  the  embedded  mission  processing  domain.  The  characterization  steps  are 
widely  applicable,  but  the  model  library  and  code  generation  steps  are  currently  applicable  to  embedded 
Ada  and  C  code.  The  IULS  toolset  is  most  valuable  for  wrappers  with  larger  data  interfaces  yet  with 
similar  patterns  and  constructs.  This  allows  the  exploitation  of  the  component  library,  class  structures  and 
autocoding. 

9.2  Upgrade  Programmatics 

Once  the  technical  aspects  of  an  upgrade  have  been  addressed,  an  even  greater  challenge  is  addressing 
the  programmatic  issues  starting  with  the  decision  to  preserve,  maintain  and  upgrade  or  rather  redesign 
the  system.  This  challenge  is  described  by  Schneidewind  for  the  IEEE  [20],  Ragland  for  the  USAF  [16], 
and  in  the  IULS  Final  Technical  Report,  Task  1.  Total  re-engineering  has  many  advantages  if  it  is 
affordable,  including  an  opportunity  to  take  control  and  document  (e.g.,  “re-baseline”)  the  design  using 
improved  methodology  and  tools  after  long  periods  of  “maintenance”. 

There  are  much-improved  software  cost  estimating  tools  available  such  as  Price  S 
[http://www.pricesvstems.com1  to  characterize  partial  redesign  (with  some  reuse),  designing  a 
replacement  from  current  requirements,  or  total  re-engineering  from  fundamental  requirements.  The  cost 
of  the  wrapper  itself  is  characterized  as  “automated  software  development”.  A  valuable  reference  with 
regard  to  re-engineering  is  the  Software  Reengineering  Assessment  Handbook  from  the  DOD  Joint  Group 
on  Systems  Engineering  [JLC-HDBK-SRAH]. 

It  is  a  fact-of-life  in  most  software  domains  that  near-term  funding  is  much  easier  to  acquire  than  long  term 
for  a  number  of  reasons.  Maintenance  and  minor  upgrades  are  generally  less  costly  and  produce 
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immediate,  identifiabie  returns  whereas  iarger,  ionger-term  re-engineering  efforts  are  more  costly  and 
promise  less  quantifiable  life-cycle  savings.  The  lULS  approach  to  upgrades  falls  somewhere  in  between. 
It  is  obvious  from  the  lULS  upgrade  projects  that  the  best  opportunity  to  re-engineer  for  upgrade  and 
reuse  is  in  conjunction  with  major  functional  or  hardware  upgrades.  This  is  also  the  best  context  for 
evaluating  the  use  of  an  emulator  wrapper.  Life  cycle  costs  must  be  analyzed  and  documented,  including 
the  increasing  cost  of  maintaining  legacy  requirements,  documentation,  and  support  software  [21].  The 
open  systems  upgrade  planning  process  can  be  aided  by  lessons-learned  from  activities  such  as  AVPLEX 
which  is  a  “Model  for  Avionics  Upgrade  Planning  and  Execution”  [13]. 

One  of  the  unstated  goals  of  the  project  was  to  generalize  the  experiences  and  lessons-learned  from  the 
case  studies  and  demonstrations  into  an  tool’s  algorithm  or  set  of  rules  to  guide  a  program  in  choosing 
between  re-engineering  and  wrapped  upgrades,  and  among  the  wrapper  approaches.  One  of  the  lessons- 
learned,  however,  was  that  this  determination  is  typically  complex  and  unique  for  every  program  because 
of  the  factors  addressed  in  the  preceding  sections.  Whilst  a  "template"  based  approach  to  determining 
upgrade  strategies  is  a  good  first  step  to  weigh  options,  our  experience  has  shown  that  each  program 
must  systematically  do  the  technical  analysis  (including  the  pre-design  phases  of  the  wrapper  process),  the 
life-cycle  analysis  (including  cost  models),  and  the  programmatic  factor  analysis  to  determine  their  best 
course  of  action. 

Tech  transition  is  achievable  (and  has  been  demonstrated  on  lULS)  but  requires  proving  the  technology 
performs,  and  performs  in  ways  that  were  not  necessarily  intended  at  design.  Tech  transition  to  a  risk 
averse  production  program  requires  constant  attention,  and  close  collaboration  and  risk  mitigation 
strategies.  The  tech  transition  path  for  an  organization  that  does  not  have  an  existing  relationship  to  the 
production  program  is  difficult  at  best  and  at  times  nearly  impossible.  Even  when  the  technology  has 
proven  itself,  production  programs  may  remain  skeptical  and  need  to  be  coaxed  into  accepting  potential 
risky  technology. 

Finally,  transition  success  can  ultimately  depend  on  factors  totally  independent  of  the  technology  value. 
The  demonstrated  value  of  the  wrapper  toolset  was  less  relevant  to  the  F-15  program  after  their  roadmap 
changed  to  embrace  an  Ada  rehost  vice  a  C-i-i-  re-engineering. 

9.3  Summary 

The  lULS  project  has  produced  a  near  turn-key  system  to  facilitate  incremental  improvements  to  fielded 
weapon  system  avionics  using  software  wrappers.  A  Software  User  Manual  is  available  that  contains 
wrapper  guidelines  and  architectures,  and  describes  the  use  of  the  WrapidH  toolset.  The  F-15  OWS,  C- 
17  ecu,  and  CV-22  demonstrations  described  in  the  report  are  real-world  examples  of  the  application  of 
the  lULS  process.. 

The  WrapidH  toolset  and  current  Wrapper  Library  are  available  from  Boeing  Phantom  Works 
[http://PhantomWorks.boeina.com]  for  installation  and  use  on  a  PC/Windows  Workstation.  The  Domain 
Modeling  Environment  is  also  available  from  the  project  or  can  be  downloaded  directly  (without  cost)  from 
Honeywell  [http://www.htc.honevwell.com/dome].  It  is  an  extensible  collection  of  integrated  model  editing, 
meta-modeling,  and  analysis  tools  (including  UML)  supporting  a  model-based  development  approach  to 
system/software  engineering  in  many  software  domains. 

The  specialized  RePLACE™  toolset  for  developing  emulation-based  embedded  software  wrappers  was 
developed  for  AFRL  by  TRW-Dayton  and  is  currently  being  employed  on  a  number  of  embedded  software 
upgrade  projects  as  well  as  the  C-17  CCU  upgrade.  It  is  available  from  TRW  [http://www.trw.com]. 

The  wrapper  approach  to  incremental  avionics  upgrades  and  enhancements  is  intuitively  appealing,  and  a 
number  of  projects  that  have  heard  about  lULS  have,  at  least,  included  the  concept  in  their  upgrade  trade 
space.  It  is  a  valuable  resource  in  the  growing  effort  to  deal  with  aging  aerospace  vehicles  and  their 
avionics.  And  it  is  coincident  with  the  development  of  upgrade  and  reuse  technology  in  many  other 
software  domains. 
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Acronyms  and  Abbreviations 

ADCP  Advanced  Display  Core  Processor  (F-15) 


ADL 

AFRL 

AIDS 

AISF 

AL 

Architecture  Description  Language 

Air  Force  Research  Lab 

Aircraft  Integrated  Data  System 

Avionics  Integration  Support  Facility  (C-17) 

Assembly  language 

API  Application  Program  Interface 

APM,  A/PDMC  Avionics/Propulsion  Data  Management  Computer  (C-17) 


ARINC 

AVMUX 

A/A 

A/G 

BIF 

BIT 

BIOS 

CAAP 

CAU 

ecu 

CFT 

CIP 

CLC 

CLD 

CNAV 

COE 

CNI 

COFP 

CONOPS 

CORBA 

COSA 

COSSI 

COTS 

CPM 

CPS 

CPU 

CRAD 

CRB 

CRT 

CSC 

C/D 

DMA 

Dome 

DPM 

DSSSL 

DTE 

EEC 

EWS 

EXEC 

FCC 

FODA 

FTR 

GATM 

GDIS 

Aeronautical  Radio,  Inc. 

Avionics  multiplex  bus 

Air-to-Air 

Air-to-Ground 

Built-In  Function 

Built-In  Test 

Basic  Operating  System 

Common  Avionics  Architecture  for  Penetration 

Cautions 

Communication  Control  Unit  (C-17) 

Conformal  fuel  tanks  (F-15) 

Core  Integrated  Processor  (C-17) 

Central  Logic  and  Control  (PARCS) 

Critical  Local  Data 

Common  Navigation 

Common  Operating  Environment 

Communication,  Navigation,  Identification 

Common  OFP  (Boeing  IRAD  project) 

Concept  of  Operations 

Common  Object  Request  Broker  Architecture 

Communication  Open  System  Architecture 

Commercial  Operations  and  Support  Savings  Initiative,  Dual  Use  Applications  Program 
Commercial  Off-the-Shelf 

Computer  Processor  Module 

Cabin,  Pressure  Sensor  (Controller) 

Central  Processing  Unit 

Contracted  Research  and  Development 

COTS  Replacement  Box  (C-17) 

Cathode  Ray  Tube 

Computer  Software  Component 

Control  and  Display 

Direct  Memory  Access 

Domain  Modeling  Environment 

Data  Processor  Module 

Document  Style  Semantics  and  Specification  Language 

Desktop  Test  Environment 

Engine,  Electronic  Control 

Early  Warning  System 

Executive 

Flight  Control  Computer 

Feature-Oriented  Domain  Analysis 

Flight  Test  Recorder 

Global  Air  Traffic  Management 

General  Dynamics  Information  Systems  (formerly  Control  Data,  “CDInt”), 
[http://www.ad-is.coml 

GP 

GSE 

HOL 

General  Purpose  (Processor) 

Ground  Support  Equipment 

High  Order  Language 
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HTC 

HS 

HSDB 

HUD 

H/W 

IBIT 

IDEF 

lEIST 

lOM 

lOP 

IRMS 

ISA 

I/O 

lULS 

JASS 

LCD 

LM 

MDA 

MC 

MCK/MCD 

MLP 

MMU 

MPDP 

MSIP 

MTA 

MUX 

NAV 

NMD 

NVRAM 

OFP 

00 

ORB 

OSCAR 

OTS 

OWS 

0/S 

PARCS 

PIM 

PML 

PROM 

RAM 

RAMP 

RCF 

RePLACE 

RFP 

RISC 

RTOS 

RTS 

SEE 

SEI 

SLOC 

SMP 

SOF 

SRAM 

SUM 

SUROM 

S/W 

TCAS 


Honeywell  Technology  Center 
Hamilton  Standard 
High  Speed  Data  Bus 
Head-Up  Display 
Hardware 
Initiated  BIT 

Integrated  Computer-Aided  Manufacturing  Definition  Language 
Insertion  of  Embedded  Infosphere  Support  Technologies 
Input/Output  Module  (F-15) 

Input/Output  Processor 

Integrated  Radio  Management  Systems  (C-17) 

Instruction  Set  Architecture 
Input/Output 

Incremental  Upgrade  of  Legacy  Systems 
Joint  Vertical  Experimental  Avionics  System  Software 
Liquid  Crystal  Display 
Lockheed  Martin 

McDonnell  Douglas  Aerospace  (now  Boeing) 

Mission  Computer 
Mission  Control  Keyboard/Display 
Memory  Loader  Program 
Memory  Management  Unit 
Multi-Purpose  Display  Processor  (F-15) 

Multi-Stage  Improvement  Program  (F-15) 

Boeing  Military  Transport  Aircraft 

Multiplex  Bus 

Navigation 

National  Missile  Defense 

Non-Volatile  RAM 

Operational  Flight  Program 

Object-Oriented 

Object  Request  Broker 

Open  Systems  Core  Avionics  Requirements 

Off-the-Shelf 

Overload  Warning  System  (F-15) 

Operating  System 

Perimeter  Attack  Radar  Characterization  System 
Process  Interface  Message  (F-15) 

Performance  Model  Library 
Programmable  Read-Only  Memory 
Random  Access  Memory 
Radar  Architecture  Migration  Program 
Radio  Control  Function  (C-17) 

Reconfigurable  Processor  for  Legacy  Avionics  Code  Execution  (TRW) 

Request  for  Proposal 

Reduced  Instruction  Set  Architecture 

Real-Time  Operating  System 

Run-Time  System  or  Software 

Software  Engineering  Environment 

Software  Engineering  Institute 

Software  Lines  of  Code 

Symmetrical  Multi-Processing 

Special  Operations  Forces 

Semiconductor  (volatile)  RAM 

Software  User  Manual 

Start-Up  Read  Only  Memory 

Software 

Traffic  Alert  and  Collision  Avoidance  Systems 
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TD 

Technology  Demonstration 

TOS 

Tactical  Operating  Systems 

UML 

Unified  Modeling  Language 

UFC 

Up  Front  Control 

VCC 

VHSIC  Central  Computer  (F-15) 

VHDL 

VHSIC  Hardware  Description  Language 

VME 

Versa  Module  Eurocard 

WAGS 

Warning  and  Cautions  System  (C-17) 

WSOA 

Weapon  System  Open  Architecture 

WSSTS 

Weapon  System  Software  Technology  Support 
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Glossary 

Architecture  -  The  high  ievei  packaging  of  functions  and  data  to  impiement  an  appiication. 

Architecture  modeiing  -  Mapping  the  domain  modei  to  a  software  architecture  to  soive  domain 
probiems. 

Context  -  The  environment  in  which  the  software  exists. 

Context  Anaiysis  -  Estabiishing  the  scope  and  environment  of  a  domain,  and  identifying  the  externai 
conditions  and  interfaces,  which  cause  variations. 

Domain  -  A  ciass  of  software  that  provides  services  for  soiving  a  simiiar  set  of  probiems  (appiications 
or  capabiiities). 

Domain  Modeiing  -  identifying  the  common  features/probiems  addressed  by  the  software  domain  using 
modeis.  A  domain  modei  defines  the  functions,  objects,  data,  and  their  reiationships  in  the  domain. 

Feature  -  A  prominent,  distinctive  characteristic  or  behavior. 

Feature  Oriented  Domain  Anaiysis  -  Aggregation  and  generaiization  to  capture  the  commonaiity  in 
software  appiications  using  the  process  of  context  anaiysis,  domain  modeiing,  and  architecture 
modeiing. 

Patterns  -  Design  patterns  provide  guideiines  for  appiying  the  reference  architecture  and  components  to 
different  domains  and  contexts. 

Reference  architecture  -  Provides  exampies,  which  are  used  as  a  guideiine  or  tempiate  for  deveioping 
the  actuai  wrapper  architecture  for  an  upgrade. 

Repository  of  components  -  A  coiiection  of  components  inciuding  primitive  wrapper  parts  and  execution 
environments  that  can  be  picked  up  by  the  tooi  to  construct  an  upgrade  wrapper. 
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Appendix  A.  Overload  Warning  System  /  Common  OFP  Mapping  Table 


F-15  0WS  PIM 

F-15COFP 

D_ADC_20HZ_INPUT_PIM 

MACH_NUMBER  :  Mach; 
type  Mach  is  new  Real  range  - 
20.0  ..  20.0; 

A5ADP.h{57):  const  BOualityDouble&  GetMach(); 

Ex.  theA5ADP_Ptr->GetMach{) 

Returns  reference  to  BqualityDouble  -  GetValue()  returns 
mach/double/dimensionless,  IsValidQ  returns  bool. 

D_ADC_20HZ_INPUT_PIM 

LOCAL_ANGLE_OF_ATTACK 
:  Cockpit_Units; 

type  Cockpit_Units  is  new  Real; 

A5ADP.h(56):  const  BAnglePiOver2&  GetLocalAngleOfAttack(); 
Ex.  theA5ADP_Ptr_->  GetLocalAngleOfAttack{).GetAngle() 

Returns  reference  to  BAnglePiOver2  - 

BAglePiOver2  derived  from  class  Bangles  -  GetAngleQ  returns 

Local  Angle  Of  Attack/double/radians  limited  to  -Pi/2  to  Pi/2. 

D_ADC_20HZ_INPUT_PIM 

LOCAL_ANGLE_OF_ATTACK 

VALID  :  Boolean; 

A5ADP.h{56):  const  BAnglePiOver2&  GetLocalAngleOfAttack{); 
Ex.  theA5ADP_Ptr_->  GetLocalAngleOfAttack().lsValid() 

Returns  reference  to  BAnglePiOver2  - 

BAglePiOver2  derived  from  class  Bangles  -  IsValidO  returns  bool 

D_ADC_20HZ_INPUT_PIM 

BARG  CORRECTED 
PRESSURE_ALTITUDE  :  Feet; 
type  Feet  is  new  Real; 

A5ADP.h(123):  const  virtual  BqualityDouble& 
GetBaroCorrectedPressureAltitudeO; 

Ex.  theA5ADP_Ptr_->  GetBaroCorrectedPressureAltitude() 

Returns  reference  to  BqualityDouble  -  GetValue()  returns  Bare 
Corrected  Pressure  Altitude/double/ft,  IsValidO  returns  bool. 

D_ADC_20HZ_INPUT_PIM 

TRUE_ANGLE_OF_ATTACK  : 
Elevation_Type; 
subtype  Elevation_Type  is 
Radians  range  -Pi  /  2.0  ..  Pi  / 

2.0; 

type  Radians  is  new  Real  range 
-3.0*  Pi  ..3.0*  Pi; 

A5ADP.h(64):  const  BAnglePiOver2&  GetTrueAngleOfAttack(); 

Ex.  theA5ADP_Ptr_->  GetTrueAngleOfAttack{) 

Returns  reference  to  BAnglePiOver2  - 

BAglePiOver2  derived  from  class  Bangles  -  GetAngleQ  returns 

True  Angle  Of  Attack/double/radians  limited  to -Pi/2  to  Pi/2, 

IsValidQ  returns  bool. 

D_ADC_20HZ_INPUT_PIM 

PRESSURE_RATIO :  Unitless; 
type  Unitless  is  new  Real; 

A5ADP.h(61):  const  BOualityDouble&  GetPressureRatioQ; 

Ex.  theA5ADP_Ptr_->  GetPressureRatioQ 

Returns  reference  to  BqualityDouble  -  GetValueQ  returns  pressure 
ratio/double/dimensionless,  IsValidQ  returns  bool. 

D_AFCS_20HZJNPUT_PIM 

MODE  DISCRETE  WORD 
.SPIN_RECOVERY_DlSPLAY  : 
Boolean; 

A5AFCS.h(98):  inline  bool  GetSpinRecoveryDisplayQ; 

Ex.  theA5AFCS_Ptr_->  GetSpinRecoveryDisplayQ 

Returns  bool  which  can  be  used  to  populate  the  appropriate  bit  in 

D  AFCS  20HZ  INPUT  PIM. PIM. MODE  DISCRETE  WORD. 
SPIN.DISCOVERY.DISPLAY 

D_AFCS_20HZJNPUT_PIM 

MODE  DISCRETE  WORD 
.LANDING_GEAR_HANDLE_ 
IS_UP  :  Boolean; 

A5AFCS.h{76):  inline  bool  GetLandingGearHandlelsUpQ; 

Ex.  theA5AFCS_Ptr_->  GetLandingGearHandlelsUpQ 

Returns  bool  which  can  be  used  to  populate  the  appropriate  bit  in 

D  AFCS  20HZ  INPUT  PIM. PIM.  MODE  DISCRETE  WORD. 
LANDING  GEAR  HANDLE  IS  UP 

D_AFCS_20HZJNPUT_PIM 

MODE  DISCRETE  WORD 
.YAW  RATE  TONE 

PRIORITY :  Boolean; 

A5AFCS.h(1 10):  inline  bool  GetYawRateTonePriorityQ; 

Ex.  theA5AFCS_Ptr_->  GetYawRateTonePriorityQ; 

Returns  bool  which  can  be  used  to  populate  the  appropriate  bit  in 

D  AFCS  20HZ  INPUT  PIM. PIM.  MODE  DISCRETE  WORD. 
YAW  RATE  TONE  PRIORITY 

D_AFCS_20HZJNPUT_PIM 

R_H_STAB  I  LATOR_RAM_ 
POSITION  :  Degrees; 
type  Degrees  is  new  Real 
range  -360.0  ..  360.0; 

A5AFCS.h{92):  const  BOualityDoubleS 

GetRH_StabRamPositionQ; 

Ex.  theA5AFCS_Ptr_->  GetRH_StabRamPositionQ; 

Returns  reference  to  BqualityDouble  -  GetValueQ  returns  RH 
Stabilator  RAM  Position/double/radians. 

D_AFCS_20HZJNPUT_PIM 

RIGHT  STAB  MAIN  RAM 

POS  IS  VALID 

D_OWS_20_HZ_LIB.pei1orm_v 
alidity_checks.ada 
Validity_Word.Right_Stab_Mai 
n_RAM_Pos_ls_Valid  : 

Boolean; 

A5AFCS.h(93):  A5AFCS.h(92):  inline  bool 
GetRightStabMainRamPosIsValidQ; 

Ex.  theA5AFCS_Ptr_->  GetRightStabMainRamPosIsValidQ; 
Returns  bool  to  be  used  for 
RIGHT_STAB_MAIN_RAM_POS_IS_VALID. 
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F-15  0WS  PIM 

F-15  COFP 

D_AFCS_20HZJNPUT_PIM 

L_H_STAB  I  LATOR_RAM_ 
POSITION  :  Degrees; 
type  Degrees  Is  new  Real 
range  -360.0  ..  360.0; 

A5AFCS.h{83):  const  BQualltyDoubleS 

GetLH_StabRamPosltlon{); 

Ex.  theA5AFCS_Ptr_->  GetLH_StabRamPosltlon(); 

Returns  reference  to  BqualltyDouble  -  GetValue{)  returns  LH 
Stabllator  RAM  Positlon/double/radlans. 

D_AFCS_20HZJNPUT_PIM 

LEFT  STAB  MAIN  RAM 

POS  IS  VALID 

D_OWS_20_HZ_LIB.perform_v 
alldlty_checks.ada 
Valldlty_Word.Left_Stab_Maln 
_RAM_Pos_ls_Valld  :  Boolean; 

A5AFCS.h{82):  A5AFCS.h(92):  Inline  bool 
GetRIghtStabMaInRamPosIsValldO; 

Ex.  theA5AFCS_Ptr_->  GetLeftStabMalnRamPoslsValld{); 

Returns  bool  to  be  used  for 
LEFT_STAB_MAIN_RAM_POS_IS_VALID. 

D_AFCS_20HZJNPUT_PIM 

ROLL_RATE : 

Radlans_Per_Sec; 

type  Radlans_Per_Sec  Is  new 

Real; 

A5AFCS.h{94):  const  BQualltyDouble&  GetRollRateQ; 

Ex.  theA5AFCS_Ptr_->  GetRollRateQ; 

Returns  reference  to  BqualltyDouble  -  GetValue()  returns  Roll 
Rate/double/radlans/sec. 

D_AFCS_20HZJNPUT_PIM 

YAW_RATE  : 

Radlans_Per_Sec; 

type  Radlans_Per_Sec  Is  new 

Real; 

A5AFCS.h{1 08):  const  BOualltyDouble&  GetYawRateQ; 

Ex.  theA5AFCS_Ptr_->  GetYawRate(); 

Returns  reference  to  BqualltyDouble  -  GetValue()  returns  Yaw 
Rate/double/radlans/sec. 

D_AFCS_20HZJNPUT_PIM 

VALIDITY  WORD.YAW 
RATE_IS_VALID  :  Boolean; 

A5AFCS.h(109):  bool  GetYawRatelsValid{); 

Ex.  theA5AFCS_Ptr_->  GetYawRatelsValld(); 

Returns  bool  to  be  used  directly  In  D  AFCS  20HZ  INPUT  PIM. 
VALIDITY_WORD.YAW_RATE_IS_VALID 

D_AFCS_20HZJNPUT_PIM 

VALIDITY  WORD.ROLL 
RATEJS_VALID  :  Boolean; 

A5AFCS.h(95):  bool  GetRollRatelsValld{); 

Ex.  theA5AFCS_Ptr_->  GetRollRatelsValld(); 

Returns  bool  to  be  used  directly  In  D  AFCS  20HZ  INPUT  PIM. 
PIM.VALIDITY  WORD.ROLL  RATE  IS  VALID 

D_AFCS_20HZJNPUT_PIM 

LATERAL_STICK_FORCE  : 
Pounds  range  -20.0  ..  20.0; 
type  Pounds  Is  new  Real; 

A5AFCS.h{79):  const  BQualltyDoubleS  GetLateralStlckForce(); 

Ex.  theA5AFCS_Ptr_->  GetLateralStlckForce(); 

Returns  reference  to  BqualltyDouble  -  GetValue{)  returns  lateral 
stick  force/double/lbs 

D_AFCS_20HZJNPUT_PIM 

LATERAL  STICK  FORCE 
IS_VALID  :  Boolean; 

A5AFCS.h(80):  bool  GetLateralStlckForcelsValld(); 

Ex.  theA5AFCS_Ptr_->  GetLateralStlckForcelsValid(); 

Returns  bool  to  be  used  directly  In 

D  AFCS  20HZ  INPUT  PIM. PIM. 

LATERAL  STICK  FORCE  IS  VALID 

D_AIU_20HZ_INPUT_PIM 

NAV_POD_PRESENT : 

Boolean; 

TGT_POD_PRESENT  : 

Boolean; 

A5AIU.h(427):  const  AIU_PodStatusType& 

GetAIU2  PodStatusO; 

Ex.  theA5AIU_Ptr_->  GetAIU2_PodStatus{); 

Returns  reference  to  PodStatusType  which  Is  a  structure  defined 

In  A5AIU2_Types.h.  PodStatusType->  NAV_podPresent  Is  bool 
which  can  be  used  to  populate  D  AlU  20HZ  INPUT  PIM. 
PIM.NAV_POD_PRESENT  and  PodStatusType-> 

TGTjDodPresent  Is  bool  which  can  be  used  to  populate 

D  AlU  20HZ  INPUT  PIM.  PIM.TGT  POD  PRESENT 

D_GEN_20HZ_UNPACK_PIM 

SAFED  OFF  WEIGHT  OFF 
WHEELS  :  Boolean; 

A5WelghtOffWheels.h{106):  Inline  bool 
GetWelghtOffWheelsSafedOffO; 

Ex.  theA5WOW_LD_Ptr_->  GetWelghtOffWheelsSafedOffO; 
Returns  bool  to  be  used  directly  In 

D  GEN  20HZ  UNPACK  PIM. 

PIM.SAFED  OFF  WEIGHT  OFF  WHEELS 

DJNS_20HZJNPUT_PIM 

NORMAL_ACCELERATION  : 
Feet_Per_Sec_Squared; 
type  Feet_Per_Sec_Squared  Is 
new  Real; 

A5INS.h(88):  const  BOualltyDoubleS  GetNormalAcceleratlon{) 

Ex.  theA5INS_Ptr_->  GetNormalAcceleratlon{) 

Returns  reference  to  BqualltyDouble  -  GetValueO  returns  Normal 
Acceleratlon/double/ft/sec2. 

DJNS_20HZJNPUT_PIM 

ALIGN  STATUS 
.GYROCOMPASS_ALIGN  : 
Boolean; 

A5INS.h{67):  const  INS_AllgnStatusType&  GetAIIgnOualltyO; 

Ex.  theA5INS_Ptr_->  GetAIIgnOualltyO; 

struct  AlIgnStatusType.  gyroCompassAIIgn  Is  bool  to  be  used  for 

ALIGN  STATUS.GYROCOMPASS  ALIGN 
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DJNS_20HZJNPUT_PIM 

ALIGN  STATUS.STORED 
HEADING_ALIGN  :  Boolean; 

A5INS.h{67):  const  INS_AllgnStatusType&  GetAlignQualltyO; 

Ex.  theA5INS_Ptr_->  GetAlignQualltyO; 

struct  AlIgnStatusType.  storedHeadIngAIIgn  Is  bool  to  be  used  for 

ALIGN  STATUS.STORED  HEADING  ALIGN 

D_lNS_20HZ_INPUT_PIM 

Inu  Status.POSITION  AND 
VELOCITY  VALID  :  Boolean; 

A5INS.h{123):  bool  GetPosltlonAndVelocltyValld{); 

Ex.  theASINS  Ptr  ->  GetPosItionAndVelocityValldO; 

DJNS_20HZJNPUT_PIM 

lnu_Status.ATTITUDE_VALID  : 
Boolean; 

A5INS.h{71):  bool  GetAttltudeValld(); 

Ex.  theASINS  Ptr  ->  GetAttItudeValldO; 

D_INS_20HZ_INPUT_PIM 

Inu  Status.BARO  INERTIAL  A 
LTITUDE  VALID 

A5INS.h(73):  bool  GetBarolnertlalAltltudeValld(); 

Ex.  theASINS  Ptr  ->  GetBarolnertlalAltItudeValldO; 

D_PACS_20HZJNPUT_PIM 

NUC_TRNG_SELECTED : 
Boolean; 

ASUPACS.h{S6):  const  ASUPACS  NucDataStructTypeS 
GetASUPACS  NucData{); 

Ex.  theASUPACS_Ptr_->  GetASUPACS_NucData{); 

Returns  reference  to  ASUPACS_NucDataStructType. 
NucTralnIngSelected  Is  bool  which  can  be  used  directly  for 

D  PACS  20HZ  INPUT  PIM. PIM.  NUC  TRNG  SELECTED. 
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D_GEN_1  OHZ_UNPACK_PIM 

BRU_STATION_WEIGHT : 

D_0  ws_T  y  pes .  Sta_2_8_5_Array_T  y  pe ; 

type  Sta_2_8_5_Array_Type  is  array 

(Sta  2  8  5  L  R  TyperanqeSta  2..Sta  5)  of 

U_Basic_Data_Types.  Pounds; 

type  Sta  2  8  5  L  R  Type  is  (Sta  2,  Sta  8,  Sta  5,  Left, 

Reft); 

type  Pounds  is  new  Reai; 

Not  avaiiabie  in  demo  eonfiguration  - 
Use  PACS  training  Capabiiity 
if  (A5UPACS_Station.stations[STA_X] 
.merPresent)  Stub  to 
BRU_STATiON_WEiGHT(STA-X)  =  0 
ibs,  eise 

BRU  STATiON  WEiGHT(STA-X)  = 

524.0  ibs  for  X=2,5,8 

D_GEN_1  OHZ_UNPACK_PIM 

CFT_STATUS_FLAG  :  Cft_Type; 
type  Cft  Type  is  (None,  Cft  4,  Cft  3); 

Not  avaiiabie  in  demo  eonfiguration  - 
Stub  to  CFT  STATUS  FLAG  =  CFT  4. 

D_GEN_1  OHZ_UNPACK_PIM 

AG_WEAPON_COUNT : 

D_Ows_T  ypes.  Ag_Weapon_Cou  nt_Array_T  ype; 
type  Ag_Weapon_Count_Array_Type  is 
array  (Sta  2  8  5  L  R  Type)  of 

U_Nu  mber_T  ypes.  lnteger_Short; 

type  Sta  2  8  5  L  R  Type  is  (Sta  2,  Sta  8,  Sta  5,  Loft, 

Reft); 

type  integer  Short  is  range -32768  ..  32767; 

Not  avaiiabie  in  demo  eonfiguration  - 
Use  PACS  training  Capabiiity 

Stub  to 

AG_WEAPON_COUNT{STA_X)  = 
A5UPACS_Stations.stations[STA_X] 
.wpnCount  for  X=2,5,8 

D_GEN_1  OHZ_UNPACK_PIM 

LAUNCHER_WEIGHT  : 

D_0  ws_T  y  pes .  Sta_2_8_Array_T  y  pe ; 

type  Sta_2_8_Array_Type  is  array 

(Sta  2  8  5  L  R  Type  range  Sta  2. .Sta  8)  of 

U_Basic_Data_Types.  Pounds; 

type  Sta  2  8  5  L  R  Type  is  (Sta  2,  Sta  8,  Sta  5,  Left, 

Reft); 

type  Pounds  is  new  Reai; 

Not  avaiiabie  in  demo  eonfiguration  - 
Stub  to  LAUNCHER  WEIGHT(STA  2) 

=  LAUNCHER_WEIGHT(STA_8)  =  0 

Ibs.  Note 

LAUNCHER_WEIGHT{STA_5)  is  not 
defined. 

D_GEN_1  OHZ_UNPACK_PIM 

PYLON_WEiGHT  : 

D_Ows_T  y  pes.Sta_2_8_5_Array_T  ype ; 

Type  Sta_2_8_5_Array_Type  is  array 

(Sta  2  8  5  L  R  Type  range  Sta  2. .Sta  5)  of 

LI_Basie_Data_Types.  Pounds; 

Type  Sta  2  8  5  L  R  Type  is  (Sta  2,  Sta  8,  Sta  5,  Left, 
Reft); 

Type  Pounds  is  new  Reai; 

Not  available  in  demo  eonfiguration  - 
Use  PACS  training  Capability 

If  {theA5UPACS_ptr- 
>GetPylonPresentSta2())  Stub  to 

PYLON  WEIGHT{STA  2)  =  500.0; 

Else  PYLON  WEIGHT(STA  2)  =0.0; 
if  (theA5UPACS_ptr- 
>GetPylonPresentSta5())  Stub  to 

PYLON  WEIGHT{STA  5)  =  300.0; 

Else  PYLON  WEIGHT(STA  5)  =0.0; 
if  (theA5UPACS_ptr- 
>GetPylonPresentSta8{))  Stub  to 

PYLON  WEIGHT{STA  8)  =  500.0; 

Else  PYLON  WEIGHT(STA  8)  =0.0; 
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D_GEN_1  OHZ_UNPACK_PIM 

AG_STATION_ID_CODE  : 

D_Ows_T  ypes.  Ag_Station_ld_Code_Array_T  y  pe ; 
type  Ag  Station  Id  Code  Array  Type  is  array 
(Sta  2  8  5  L  R  Type)  of 

U_Pacs_Types.Ag_Store_Type; 

Type  Sta  2  8  5  L  R  Type  is  (Sta  2,  Sta  8,  Sta  5,  Loft, 
Reft); 

type  Ag  Store  Type  is  (None,  Mk  82,  Mk  82Se,  Me  1 , 

Mk  84,  Mk  82Ar,  Mk  84Ar,  Bdu  33,  Cbu  52,  Cbu  58, 
Cbu_71 ,  Cbu_87,  Cbu_89,  Cbu_97,  Spare_14, 

Spare_15,  Suu_20,  Suu_20M,  Suu_20N,  Mk_20, 

Agm  65A,  Agm  65B,  Agm  65D,  Agm  65G,  Gbu  15S, 
GbuJOA,  GbuJOM,  Gbu_12B,  Gbu_12C,  Gbu_15L, 

Tgbu  15,  Gbu  24,  Axq  14,  Unknown,  Mxu  648,  Idip, 

Fuel,  Spare_37,  Alq_119,  Alq_131 ,  Blu_107,  GbuJOB, 
Spare_42,  Spare_43,  Gbu_24A,  Gbu_28,  Agnn_130A, 
Agm_130C,  Tgm_65A,  Tgm_65B,  Tgm_65D,  Tgm_65G, 
Spare_52,  Spare_53,  Spare_54,  Spare_55,  Spare_56, 
Spare_57,  Spare_58,  Spare_59,  Spare_60,  Spare_61 , 
Spare_62,  Spare_63,  Spare_64,  Spare_65,  Spare_66, 
Spare_67,  Spare_68,  Spare_69,  Spare_70,  Spare_71 , 
Spare_72,  Spare_73,  Spare_74,  Spare_75,  Spare_76, 
Spare_77,  Spare_78,  Spare_79,  Spare_80,  Spare_81 , 
Spare_82,  Spare_83,  Spare_84,  Spare_85,  Spare_86, 
Spare_87,  Spare_88,  Spare_89,  Spare_90,  Spare_91 , 
Spare  92,  Spare  93,  Spare  94,  Spare  95,  Spare  96, 
Spare  97,  Spare  98,  B61  0,  B61  10,  B61  2,  B61  3, 

B61  4,  B61  5): 

Not  available  in  demo  eonfiguration  - 
Use  PACS  training  Capability 

Stub  to  : 

AG_STATION_lD_CODE(STA_X)  = 
A5UPACS_Stations.stations[STA_X] 
■StoreLoaded  for  X=2,5,8 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_2A_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_2B_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_8A_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_8B_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_3_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_4_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_6_MISSILE_WEIGHT_FLAG  : 
U_Basie_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

AA_STA_7_MISSILE_WEIGHT_FLAG  : 
U_Basic_Data_Types.  Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  eonfiguration  - 
Stub  to:  0  lbs 

D_GEN_1  OHZ_UNPACK_PIM 

TANK_PRESENT :  D_Ows_Types. 

Tank_Present_Array_Type; 

type  Tank_Present_Array_Type  is 

array  (Sta  2  8  5  L  R  Type  ranqe  Sta  2  ..  Sta  5)  of 

Boolean; 

type  Sta  2  8  5  L  R  Type  is  (Sta  2,  Sta  8,  Sta  5,  Left, 
Reft); 

Not  available  in  demo  eonfiguration  - 
Stub  to  TANK  PRESENT{STA  2)  = 
TANK  PRESENT(STA  8)  = 

TANK  PRESENT{STA  5)  =  False. 
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D_GEN_1  OHZ_UNPACK_PIM 

RIGHT_CFT_AG_WPN_IDENT_CODE  : 

U_Pacs_T  y  pes.  Ag_Store_T  ype ; 
type  Ag  Store  Type  is  (None,  Mk  82,  Mk  82Se,  Mo  1 , 
Mk_84,  Mk_82Ar,  Mk_84Ar,  Bdu_33,  Cbu_52,  Cbu_58, 
Cbu_71 ,  Cbu_87,  Cbu_89,  Cbu_9,  Spare_14,  Spare_15, 
Suu_20,  Suu_20M,  Suu_20N,  Mk_20,  Agm_65A, 

Agm  65B,  Agm  65D,Agm  65G,  Gbu  15S,  Gbu  10A, 
GbuJOM,  Gbu_12B,  Gbu_12C,  Gbu_15L,  TgbuJS, 

Gbu  24,  Axci_14,  Unknown,  Mxu  648,  Idip,  Fuel, 

Spare_37,  Alq_1 1 9,  Alq_1 31 ,  Blu_1 07,  Gbu_1  OB, 
Spare_42,  Spare_43,  Gbu_24A,  Gbu_28,  Agm_130A, 
Agm_130C,  Tgm_65A,  Tgm_65B,  Tgm_65D,  Tgm_65G, 
Spare_52,  Spare_53,  Spare_54,  Spare_55,  Spare_56, 
Spare_57,  Spare_58,  Spare_59,  Spare_60,  Spare_61 , 
Spare_62,  Spare_63,  Spare_64,  Spare_65,  Spare_66, 
Spare_67,  Spare_68,  Spare_69,  Spare_70,  Spare_71 , 
Spare_72,  Spare_73,  Spare_74,  Spare_75,  Spare_76, 
Spare_77,  Spare_78,  Spare_79,  Spare_80,  Spare_81 , 
Spare_82,  Spare_83,  Spare_84,  Spare_85,  Spare_86, 
Spare_87,  Spare_88,  Spare_89,  Spare_90,  Spare_91 , 
Spare  92,  Spare  93,  Spare  94,  Spare  95,  Spare  96, 
Spare  97,  Spare  98,  B61  0,  B61  10,  B61  2,  B61  3, 

B61  4,  B61  5): 

Not  available  in  demo  configuration  - 
Stub  to 

RIGHT  CFT  AG  WPN  IDENT  CODE 
=  NONE. 

D_GEN_1  OHZ_UNPACK_PIM 

LEFT_CFT_AG_WPN_IDENT_CODE  : 

U_Pacs_T  y  pes.  Ag_Store_T  ype ; 

type  Ag  Store  Type  is  (None,  Mk  82,  Mk  82Se,  Me  1 , 

Mk  84,  Mk  82Ar,  Mk  84Ar,  Bdu  33,  Cbu  52,  Cbu  58, 
Cbu_71 ,  Cbu_87,  Cbu_89,  Cbu_97,  Spare_14, 

Spare_15,  Suu_20,  Suu_20M,  Suu_20N,  Mk_20, 

Agm  65 A,  Agm  65B,  Agm  65D,  Agm  65G,  Gbu  15S, 
GbuJOA,  GbuJOM,  GbuJ2B,  GbuJ2C,  GbuJ5L, 

Tgbu  15,  Gbu  24,  Axq  14,  Unknown,  Mxu  648,  Idip, 

Fuel,  Spare_37,  Alq_1 19,  Alq_131 ,  Blu_107,  Gbu  JOB, 
Spare_42,  Spare  J3,  Gbu_24A,  Gbu_28,  Agm_130A, 
AgmJ30C,  Tgm_65A,  Tgm_65B,  Tgm_65D,  Tgm_65G, 
Spare_52,  Spare_53,  Spare_54,  Spare_55,  Spare_56, 
Spare_57,  Spare_58,  Spare_59,  Spare_60,  Spare_61 , 
Spare_62,  Spare_63,  Spare_64,  Spare_65,  Spare_66, 
Spare_67,  Spare_68,  Spare_69,  Spare_70,  Spare_71 , 
Spare_72,  Spare_73,  Spare_74,  Spare_75,  Spare_76, 
Spare_77,  Spare_78,  Spare_79,  Spare_80,  Spare_81 , 
Spare_82,  Spare_83,  Spare_84,  Spare_85,  Spare_86, 
Spare_87,  Spare_88,  Spare_89,  Spare_90,  Spare_91 , 
Spare  92,  Spare  93,  Spare  94,  Spare  95,  Spare  96, 
Spare  97,  Spare  98,  B61  0,  B61  10,  B61  2,  B61  3, 

B61  4,  B61  5): 

Not  available  in  demo  configuration  - 
Stub  to 

LEFT  CFT  AG  WPN  IDENT  CODE 
=  NONE. 

D_GEN_1  OHZ_UNPACK_PIM 

RIGHT_CFT_AG_WPN_COUNT_FLAG  : 

U_Com  mon_T  ypes.Three_Bits ; 

subtype  Three_Bits  is  lnteger_Short  range  0  ..  7; 

type  Integer  Short  is  range -32768  ..  32767; 

Not  available  in  demo  configuration  - 
Stub  to 

RIGHT  CFT  AG  WPN  COUNT  FLA 

G  =  0 

D_GEN_1  OHZ_UNPACK_PIM 

LEFT_CFT_AG_WPN_COUNT_FLAG  : 

U_Com  mon_T  ypes.Three_Bits ; 

subtype  Three_Bits  is  lnteger_Short  range  0  ..  7; 

type  Integer  Short  is  range -32768  ..  32767; 

Not  available  in  demo  configuration  - 
Stub  to 

LEFT  CFT  AG  WPN  COUNT  FLAG 
=  0 
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D_GEN_20HZ_UNPACK_PIM 

PACS_COMBAT_MODE_MISSILE_PRESENT: 
Pacs_Combat_Mode_Missile_Present_Type; 
type  Pacs_Combat_Mode_Missile_Present_Type  is 
array  (U_Pacs_Types.Weapon_Sta_Type)  of  Boolean; 
type  Weapon_Sta_Type  is  (Sta_2A,  Sta_2B,  Sta_8A, 

Sta  8B,  Sta  3,  Sta  4,  Sta  6,  Sta  7,  Sta  2,  Sta  8, 

Sta_5); 

Not  available  in  demo  configuration  - 
Stub  to 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  2A)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  2B)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  8A)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  8B)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  3)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  4)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  6)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  7)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  2)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENT(STA  8)  = 

PACS  COMBAT  MODE  MISSILE  P 
RESENTfSTA  5)  =  False. 

D_GEN_20HZ_UNPACK_PIM 

ADC_INVALID_FLAG  ADC  :  Boolean; 
will  not  be  used!!!(ADP) 

Not  available  in  COSSI  -  Stub  to 

ADC  INVALID  FLAG^False 

D_GEN_20HZ_UNPACK_PIM 

SPIKE_CHECK_DATAJS_SPIKED  : 

Spike_Check_Data_ls_Spiked_Type; 

type  Spike_Check_Data_ls_Spiked_Type  is 

array  (Spike_Parameter_Type)  of  Boolean; 

type  Spike_Parameter_Type  is  {True_Aoa,  Local_Aoa, 

Mach_Number,  Pressure_Ratio, 

Baro_Corr_Press_Altitude,  Pressure_Altitude, 
Normal_Acceleration); 

Not  available  in  COSSI  -  Stub  to 

SPIKE  CHECK  DATA  IS  SPIKED(T 
RUE  AOA)  = 

SPIKE  CHECK  DATA  IS  SPIKED(L 
OCAL  AOA)  = 

SPIKE  CHECK  DATA  IS  SPIKED(M 
ACH  NUMBER)  = 

SPIKE  CHECK  DATA  IS  SPIKED(P 
RESSURE  RATIO)  = 

SPIKE  CHECK  DATA  IS  SPIKED{B 
ARO  CORR  PRESS  ALTITUDE)  = 
SPIKE  CHECK  DATA  IS  SPIKED(P 
RESSURE  ALTITUDE)  = 

SPIKE  CHECK  DATA  IS  SPIKED{N 
ORMAL  ACCELERATION)  =  False 

D_HUD_CONTROL_PIM 

AOA_LIMIT.DISPLAYED_VALUE  :  Num.lnteger_Short 
range  20 ..  50; 

type  lnteger_Short  is  range  -32768  ..  32767; 

Not  available  in  demo  configuration  - 
Stub  to  50  cockpit  units  (Note  stub  is 
short  integer  type)  to  ensure  logic  to 
activate  tone  is  not  entered  (tone 
capability  is  not  wired  in  airplane) 

D_MPDP_20HZJNPUT_PIM 

GRP_ACTIVE  :  Grp_Active_Array; 

type  Grp_Active_Array  is  array  (Side_A_B)  of 

M  pdpt .  G  rp_Acti  ve_T  y  pe ; 

type  Side_A_B  is  {Side_A,  Side_B); 

type  Grp_Active_Type  is  array  (Cmt.Du_Type)  of 

Boolean; 

for  Grp  Active  Type'Size  use  8; 

Not  available  in  demo  configuration  - 
Stub  GRP_ACTIVE(SIDE_B)(DU7)  to 
True 

D_MPDP_20HZJNPUT_PIM 

GRP_ASSIGNED_TO_BUS_B  : 
Grp_Assigned_To_Bus_B_Array; 
type  Grp_Assigned_To_Bus_B_Array  is 
array  (Side_A_B)  of 

Mpdpt.Grp_Assigned_To_Bus_B_Type; 

type  Side_A_B  is  {Side_A,  Side_B); 

type  Grp_Assigned_To_Bus_B_Type  is  array 

(Cmt.Du_Type)  of  Boolean; 

for  Grp  Assigned  To  Bus  B  Tvoe'Size  use  8: 

Not  available  in  demo  configuration  - 
Stub  GRP  ASIGNED  TO  BUS  B 
(SIDE_B)(DU7)  to  True 
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D_MPDP_20HZJNPUT_PIM 

CAU_NORMAL_ACCELERATION  :  Bdt.G_Accel; 
type  G_Accel  is  new  Real  range  -1 6.0  ..  1 6.0; 

--  Acceleration,  gravities 

Not  available  in  demo  configuration  -- 
Use  INS  value  as  default. 

A5INS.h(88);  const  BQualityDouble& 
GetNormalAccelerationO 

Ex.  theA5INS_Ptr_-> 
GetNormalAccelerationO 

Returns  reference  to  BqualityDouble  - 
GetValueO  returns  Normal 
Acceleration/double/ft/sec2.  (Convert 
from  ft/sec2  to  g’s  for 
CAU_NORMAL_ACCELERATION) 
IsValidO  returns  bool. 

D_MPDP_20HZJNPUT_PIM 

LEFT_CFT_FUEL_WEIGHT :  Bdt.Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  configuration  - 
Stub  to  4524.  lbs 

D_MPDP_20HZ_INPUT_PIM 

RIGHT_CFT_FUEL_WEIGHT ;  Bdt.Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  configuration  - 
Stub  to  4524.  lbs 

D_MPDP_20HZJNPUT_PIM 

TOTAL_FUEL_WEIGHT :  Bdt.Pounds; 
type  Pounds  is  new  Real; 

Not  available  in  demo  configuration  - 
Stub  to  13300  lbs 

If  VALUE  entered  from  scratch-pad, 
TOTAL_FUEL_WEIGHT=VALUE*1 00 
lbs  limited  0  to  1 3300  lbs. 

D_MPDP_20HZJNPUT_PIM 

GP_ROTATING_BIT_PATTERN  :  Mpdpt. 

Gp_Rotati  ng_Bit_Pattern_T  ype ; 

type  Gp_Rotating_Bit_Pattern_Type  is  (Frame_0, 

Frame_1 ,  Frame_2,  Frame_3); 

Not  available  in  demo  configuration  - 
SetGP  ROTATING  BIT  PATTERN  = 
FRAME  0, 

FRAME_1  ,FRAME_2,FRAME_3  on  a 
rotating  basis  at  20  FIz. 

D_MPDP_20HZJNPUT_PIM 

OWS_RESET_SWITCH_DEPRESSED  :  Boolean; 

Not  available  in  demo  configuration  - 
Stub  to  False 

D_PACS_20HZJNPUT_P1M 

PACS_INOPERATIVE_RESET_BIT_FLAG  :  Boolean; 

Not  available  in  demo  configuration  - 
Stub  to 

PACSJNOPERATIVE_RESET_BIT_F 
LAG  =  False 

D_PACS_20HZJNPUT_PIM 

UNKNOWN_WPN_WEIGHT_CLASS  : 
Pacst.Unknown_Wpn_Weight_Class_Type; 
type  Unknown_Wpn_Weight_Class_Type  is  (Ows_Off, 
Class  1,  Class  2,  Class  3); 

Not  available  in  demo  configuration  - 
Options  are  OWS_OFF,  CLASS_1 , 
CLASS  2,  CLASS  3.  For  demo  stub 
toOWS  OFF. 

1  PACS  CMBT  TRNG 

BUFFER 

MSG_06_WORD_1 0.NUC_TRNG_LOAD_RC  : 

U_Pacs_T  y  pes .  N  uc_T  rai  n  I  ng_Sto  re ; 

type  Nuc_Training_Store  is  (None,  Spare_1 ,  Suu_20, 

Spare_2,  Bdu_38); 

Not  available  in  demo  configuration  -  It 
is  set  equal  to  a 

NUC_TRNG_LOAD_TYPE  which  is  set 
equal  to  an  element  from 

NUC  TRAINING  STORE.  Options  for 
NUC  TRAINING  STORE  are  NONE, 
SPARE_1 ,  SUU_20,  SPARE_2  and 

BDU  38.  For  demo,  stub  to  NONE. 

1  PACS  CMBT  TRNG 

BUFFER 

MSG_06_WORD_08.NUC_TRNG_LOAD_LC 
U_Pacs_Types.Nuc_Training_Store; 
type  Nuc_Training_Store  is  (None,  Spare_1 ,  Suu_20, 
Spare_2,  Bdu_38); 

Not  available  in  demo  configuration  -  It 
is  set  equal  to  a 

NUC_TRNG_LOAD_TYPE  which  is  set 
equal  to  an  element  from 

NUC  TRAINING  STORE.  Options  for 
NUC  TRAINING  STORE  are  NONE, 
SPARE_1 ,  SUU_20,  SPARE_2  and 

BDU  38.  For  demo,  stub  to  NONE. 

X_EXECUTIVE_CONTROL 

FIRST_PASS_FOR_10_HZ  :  First_Pass_Flag_Type; 
type  First_Pass_Flag_Type  is  (Not_First_Pass, 

Power_Up,  Pilot_Reset,  Reconfiguration); 

(Note  change  of  variable  name  from  . . .  1 0FIZ  to  . . .  1 0_FIZ) 

Not  available  in  demo  configuration  - 
Options  are  NOT  FIRST  PASS, 

POWER  UP,  PILOT  RESET  and 
RECONFIGURATION.  Set  to 

POWER  UP  for  first  execution  of  1 0HZ 
and  10HZ  WARN,  NOT_FIRST_PASS 
for  subsequent  executions. 
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X_EXECUTIVE_CONTROL 

H2_PERIPHERAL_DATA_INVALID  : 

H9_Peripheral_Data_l  n  valid_T  ype ; 

type  H9_Peripheral_Data_lnvalid_Type  is  array 

(H9_Peripheral_Type)  of  Boolean; 

type  H9_Peripheral_Type  is  (Dbiu,  Ado,  Ahrs,  Spare_3, 

Spare_4,  Spare_5,  Pacs,  Spare_7,  Sdrs,  Spare_9, 

Spare_1 0,  Rwr,  Spare_1 2,  Spare_1 3,  --  SPARE_1 3  is 

reserved  for  AHRS  problem  workaround  Si,  Ics); 

Not  available  in  demo  configuration?  - 
Stub  to 

X  EXECUTIVE  CONTROL.H2  DATA. 
H2  PERIPHERAL  DATA 
INVALID(PACS)  =  False 

X_EXECUTIVE_CONTROL 

DISP_20_HZ_PERIPHERAL_DATAJNVALID  : 

Disp_Peripheral_Data_lnvalid_Type; 
type  Disp_Peripheral_Data_lnvalid_Type  is 
array  {Disp_Peripheral_Type)  of  Boolean; 
type  Disp_Peripheral_Type  is  (Reserved_0,  Spare_1 , 
Spare_2,  Spare_3,  Spare_4,  Spare_5,  Spare_6, 

Spare_7,  Spare_8,  Spare_9,  Spare_1 0,  Spare_1 1 , 
Spare_1 2,  Spare_1 3,  Spare_1 4,  Spare_1 5,  Mpdpa, 
Mpdpb,  Spare_18,  Spare_19,  Spare_20,  Spare_21 , 
Spare_22,  Spare_23,  Spare_24,  Spare_25,  Spare_26, 
Spare  27,  Spare  28,  Spare  29,  Co  Rt,  Reserved  31); 

Not  available  in  demo  configuration? - 
Stub  to 

X  EXECUTIVE  CONTROL.A1  DATA. 
DISP  20  HZ  PERIPHERAL  DATA 
INVALID(D  MPDP  PACKING  PIM. PI 
M.GPIO)=False 

X  EXECUTIVE  CONTROL.A1  DATA. 
DISP  20  HZ  PERIPHERAL  DATA 
INVALID(MPDPB)=False 

X_EXECUT1VE_C0NTR0L 

DISCRETEJNPUTS  :  Discrete_lnputs_Type; 
type  Discrete_lnputs_Type  is  array 
(Discretejnputsjndex)  of  Boolean; 
for  Discrete_lnputs_Type'Size  use  16; 
type  Discrete_lnputs_lndex  is  (Aiu1_Go,  Unused_2,  El , 
Unused_4,  Unused_5,  Unused_6,  Unused_7,  Unused_8, 
Unused_9,  Unused_10,  Unused_11,  Unused_12, 

Unused  13,  Unused  14,  Unused  15,  Unused  16); 

Stub 

X  EXECUTIVE  CONTROL.PIM.DISC 
RETEJNPUTS{E1)  =  TRUE 

X_EXECUTIVE_CONTROL 

AV_PERIPHERAL_DATAJNVALID  : 

Av_Peripheral_Data_lnvalid_Type; 
type  Av_Peripheral_Data_lnvalid_Type  is  array 
(Av_Peripheral_Type)  of  Boolean; 
for  Av_Peripheral_Data_lnvalid_Type'Size  use  32; 
type  Av_Peripheral_Type  is  (Reserved_0,  Redu, 

Spare_2,  Spare_3,  Gps,  Ins,  Spare_6,  Spare_7,  Sfdr, 

Ledu,  Radar,  Rwr,  Reserved_Mpdp,  Spare_13, 

Spare_14,  Ics,  Spare_16,  Map,  AiulA,  AiulB,  Aiu2, 
Nav_Pod,  Tgt_Pod,  Afcs,  Adp,  Spare_25,  Spare_26, 

Spare  27,  Spare  28,  Si,  Co  Rt,  Reserved  31); 

Not  available  in  demo  configuration?  -- 
Stub  to 

X  EXECUTIVE  CONTROL.AI  DATA. 
AV_PERIPHERAL_DATA_INVALID{IN 

S)  =  False 

X  EXECUTIVE  CONTROL.AI  DATA. 
AV  PERIPHERAL  DATA  INVALID{A 
FCS)  =  False 
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D  DISPLAY  MGMT  PIM 


FORMAT_LOCATION_INDICATOR_ARRAY(OWS)  : 

Format_Locatlon_lndlcator_Array_Type; 
type  Format_Location_lndlcator_Array_Type  Is 

array  (Cmt.Fornnat_Type)  of  Cmt.Du_Locatlon_Type; 
subtype  Format_Type  Is  Format_Codes_Type  range 
None ..  Srad; 

type  Format_Codes_Type  Is 

-  MENU  1  FORMATS 

(None,  -  0  also  HUD 

EadI,  - 1 

Armt,  --  2 

EhsI,  -3 

Tf_Rdr,  -  4 

Tsd,  -  5 

Menu_1_Pb_6_Reserved,  --6 
Menu_1_Pb_7_Reserved,  --7 
Menu_1_Pb_8_Spare,  --8 

Menu_1_Pb_9_Spare,  --9 

Vtrs,  - 1 0 

Menu_2,  -- 1 1 

Tgt_lr,  - 1 2 

Tews,  --13 

Ag_Rdr,  -14 

Aa_Rdr,  -15 

Menu_1  _Pb_1 6_Spare,  -  1 6 
Hud_Repeater,  - 1 7 

Eng,  -18 

Event,  - 1 9 

Bit,  -  20 

-  MENU  2  FORMATS 


Not  available  in  demo  configuration  - 
Stubto^NONE 


Wind_Model, 

Ag_Delivery, 

Menu_2_Pb_ 

Menu_2_Pb_ 

Data_Frame, 

Menu_2_Pb 

Menu_2_Pb 

Menu_2_Pb 

Menu_2_Pb 

Ows, 

Menu_1 , 

Menu_2_Pb 

Menu_2_Pb 

Menu_2_Pb 

Menu_2_Pb 

Vid_8, 

Hud_Prog, 

Vid_5, 

Dtm, 

Vid  2, 


3_Spare, 

4_Spare, 

.6_Reserved 

7_Reserved 

.8_Spare, 

.9_Spare, 


1 2_Spare, 
1 3_Spare, 
1 4_Spare, 
1 5_Spare, 


-21 
-  22 

-  23 

-  24 

-  25 

,  -26 
,  --27 

-  28 

-  29 
30 
-31 

-  32 

-  33 

-  34 
-35 

-36 

-37 

-38 

39 

40 


-  FORMATS  NOT  ON  MENU 

Srad,  Spare42,  Spare43,  Spare44,  Spare45,  Spare46, 
Spare47,  Spare48,  Spare49,  Spare50,  Spare51 , 
Spare52,  Spare53,  Spare54,  Spare55,  Spare56, 
Spare57,  Spare58,  Spare59,  Spare60,  Spare61 , 
Spare62,  Spare63); 
subtype  Du_Location_Type  is 
Refresh_Bufr_Location_Type  range  None  ..  Du7; 
type  Refresh_Bufr_Location_Type  is  (None,  DuO,  Hud, 
Du2,  Du3,  Du4,  Du5,  Du6,  Du7,  Macro  Subs,  Cautions); 
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D_DISPLAY_MGMT_PIM 

DISPLAY  BUFFER  ARRAY. 
PUSHBUTTON_DEPRESSION_NUMBER 
Dlsplay_Buffer_Array  :  Display_Buffer_Array_Type; 
type  Dlsplay_Buffer_Array_Type  Is  array  (Cmt.Du_Type) 
of  Dlsplay_Buffer_Type; 

subtype  Du_Type  Is  Du_Locatlon_Type  range  DuO  ..  Du7; 
subtype  Du_Locatlon_Type  Is 

Refresh_Bufr_Locatlon_Type  range  None  ..  Du7; 
type  Refresh_Bufr_Locatlon_Type  Is  (None,  DuO,  Flud, 

Du2,  Du3,  Du4,  Du5,  DuO,  Du7,  Macro_Subs,  Cautions); 
Pushbutton_Depresslon_Number : 
Mpdpt.Du_Pushbutton_Type; 

subtype  Du_Pushbutton_Type  Is  Du_Swltch_Code_Type 
range  None ..  Pb_20; 

type  Du  Switch  Code  Type  Is  (None,  Pb  1,Pb  2, 

Pb  3,  Pb  4,  Pb  5,  Pb  6,  Pb  7,  Pb  8,  Pb  9,  Pb  10, 
Pb_11,  Pb_12,  Pb_13,  Pb_14,  Pb_15,  Pb_16,  Pb_17, 
Pb_18,  Pb_19,  Pb_20,  Spare_21 ,  Spare_22,  Spare_23, 
Brlght_lncrease,  Brlght_Decrease,  Contrast_lncrease, 
Contrast_Decrease,  Spare_28,  Spare_29,  Spare_30, 
Initiated  Bit): 

Not  available  In  demo  configuration.  It 
will  not  be  accessed  If 

FORMAT  LOCATION  INDICATOR  A 
RRAY(OWS)==NONE.  Can  be  stubbed 
to  =CLR  for  completeness,  but  not 
required. 

N  ENGINE  MONITOR  05HZ 
_PIM 

IPE_INSTALLED  :  Boolean; 

A5EDU.h(80):  XTypes::Ulnt16 
GetTypeOfEngIneO; 

Compare:  theLEDU_Ptr- 
>GetTypeOfEnglne{)==PW229  And 
theREDU_Ptr- 

>GetTypeOfEngine{)==PW229 

If  both  are  true,  IPE_INSTALLED  = 

True,  else  False 
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File  generated  by  WrapidH,  version  1 .1 
*********************************************^ 

#include  "D_OWS_10_HZ_C_PIM.h'' 

#include  "D_OWS_20_HZ_C_PIM.h'' 

#include  "ASADP.h"  Uses  the  Host’s  ADP  aircraft  state  data 

#include  "D_ADC_C_PIM.h'' 

#include  ''D_AFCS_C_PIM.h" 

#include  ''ASAFCS.h'' 

#include  "D_MPDP_C_PIM.h'' 

#include  "BQualityDouble.h" 

#include  ''ASAIU.h" 

#include  "D_AIU_C_PIM.h'' 

#include  ''ASEDU.h'' 

#include  "N_ENGINE_MONlTOR_05HZ_C_PIM.h" 

#include  "ASUPACS.h" 

#include  '’D_PACS_C_PIM.h" 

#include  "ASWeightOffWheels.h" 

#include  "D_GEN_20HZ_C_PIM.h'' 

#include  ''ASINS.h'' 

#include  "BAnglePiOver2.h'' 

#include  "DJNS_C_PIM.h" 

#include  "D_OWS_TYPES.h" 
include  '’U_BASIC_DATA_TYPES.h'' 

#include  "INTERFACES.C.h" 

#include  "U_NUMBER_TYPES.h" 

#include  "XTypes.h" 

#include  "Unknown. h" 

#include  "A5AIU2_Types.h" 

#include  "A5ADP_Device.h" 

#include  "A5AFCS_Device.h" 

#include  "A5AIU_Device.h" 

#include  "A5EDU_Device.h" 

#include  "A5UPACS_Device.h" 

#include  "A5WeightOffWheels_Device.h" 

#include  "A5INS_Device.h" 

#include  "OWS_Wrapper.h"  Uses  the  top-level  wrapper 

class  OWS_Wrapper  { 
public: 

OWS_Wrapper(); 

Boolean  GetAOA_THRESHOLD_EXCEEDED{); 

FIXED_POINT_SHORT_SCALE_17_TYPEGetBIT_AUDIT_TOTAL_AlRCRAFT_WEIGHT(); 

Boolean  GetCAU_FAILURE_DETECTED(); 

Boolean  GetCAU_FAILURE_DETECTED_THIS_PASS(); 
G_ACCELGetCAU_NZ_LOAD_FACTORJNPUT(); 

Boolean  GetCAU_NZ_MONITOR_ON{); 

CFT_TABLE_TYPEGetCFT_FUEL_WEIGHT(); 

CJIoat  GetCFT_NZ_ALLOWABLE(); 

CFT_TABLEJNDEX_TYPEGetCFT_TABLE_INDEX{); 

CFT_TABLE_TYPEGetCFT_TOTAL_WEIGHT(); 

WARNING_RATIO_TYPEGetCFT_WARNING_RATIO{); 

DECIMAL_DEGREES  GetDECIMAL_AOA(); 

INTEGER_SHORTGetDEFAULT_AOA_TONE_LlMIT(); 

Boolean  GetDlSPLAY_BLANKS_FOR_AOA{); 

POUNDS_PER_SQUARE_FOOT  GetDYNAMIC_PRESSURE(); 

FU\G_TYPE_FOR_DTM_WRITE  GetEND_OF_EVENT_FOR_DTM_WRITE(); 

Boolean  GetFIRST_CAU_FILTER_PASS(); 

CJIoat  GetFWD_FUSELAGE_NZ_ALLOWABLE(); 

CJIoat  GetFWD_FUSELAGE_WARN_RATIO{); 

Boolean  GetGOTO_END_OF_CALC_MASS_ITEMS(); 

Boolean  GetHUDJNVALID_ARMT_DISP(); 

Boolean  GetlNFLIGHT_INVALID_ARMT_DISP(); 

Boolean  GetlNS_GROUND_ALIGN_COMPLETE{); 

G_ACCELGetlNS_NZ_LOAD_FACTORJNPUT{); 

G_ACCELGetLAST_PASS_CAU_FILTER_OUTPUT(); 

G_ACCEL  GetLAST_PASS_CAU_NZ{); 

G_ACCELGetLAST_PASS_INS_FILTER_OUTPUT(); 

POUNDS  GetLAST_PASS_LATERAL_STICK{); 
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G_ACCELGetLAST_PASS_NORMAL_ACCELERATION(); 

Boolean  GetLATCH_CAU_FAILURE(); 

WARNING_RATIO_TYPE  GetLEFT_TAIL_WARNING_RATIO{); 

Boolean  GetLOAD_FACTOR_IS_VALI  D() ; 

CJIoatGetMASSJTEMS_WARN_RATIO{); 

REAL  GetMAX_NEGATIVE_MAGNITUDE_G{); 

REAL  GetMAX_POSITIVE_MAGNITUDE_G(); 

RECALL_DATA_COMPONENT_TYPEGetMOST_RECENT_DISPLAY_INDEX(); 

REAL  GetMOST_RECENT_DISPLAY_NZ{);  Declares  the  sample  variable 

WARNING_RATIO_TYPEGetMOST_RECENT_DISPLAY_RATIO(); 

Boolean  GetNAV_LANTIRN_POD_ON_BOARD(); 

FLAG_TYPE_FOR_DTM_WRITEGetNEW_PEAK_FOUND_FOR_DTM_WRITE(); 

NZ_RECALL_TABLE_TYPEGetNZ_RECALL_TABLE{); 

Boolean  GetNZ_SOURCESJNVALID(); 

Boolean  GetOWS_CLEAR_ENABLED_FLAG(); 

OWS_FUEL_VALIDITY_TYPEGetOWS_FUEL_VALIDITY_FLAG{); 

OWS_VALIDITY_TYPEGetOWS_VALIDITY_FLAG(); 

OWS_20HZ_VALIDITY_TYPE  GetOWS_VALIDITY_FLAG(); 

Boolean  GetOWS_WARN_RATIO_THRESHOLD_EXCEEDED(); 

REAL  GetPYLON_NZ_ALLOWABLE{); 

WARNING_RATIO_TYPEGetPYLON_WARNING_RATIO{); 

Boolean  GetRESET_DTM_MAX_RATIO_VARIABLES(); 

Boolean  GetRESET_MANUAL_CLEAR_FLAGS{); 

Boolean  GetRESET_MAX_MIN_G_VALUES(); 

Boolean  GetRESET_RECALL_TABLE_FLAGS(); 

Boolean  GetRESET_VOICE_COUNTER{); 

WARNING_RATIO_TYPEGetRIGHT_TAIL_WARNING_RATIO{); 

Boolean  GetSET_ASP_LATCH_FOR_INVALID_ARMT(); 

STATION_WEIGHT_TABLE_TYPEGetSTATION_WEIGHT(); 

Boolean  GetTGT_LANTIRN_POD_ON_BOARD(); 

POUNDS  GetTOTAL_AIRCRAFT_WEIGHT(); 

POUNDS  GetTOTAL_OLD_FUEL_WEIGHT(); 

WARNING_RATIO_RECALL_TABLE_TYPEGetWARNING_RATIO_RECALL_TABLE(); 

REAL  GetWING_C_CONST_MODIFIER(); 

REAL  GetWING_NZ_ALLOWABLE(); 

WARNING_RATIO_TYPE  GetWING_WARNING_RATIO(); 

void  InitializeO;  Declares  the  four  major  wrapper  processes 

void  PERFORM_OWS_1  OHZ_NZ_WARN_Wrapper{); 
void  PERFORM_OWS_10_Hz_Wrapper{); 
void  PERFORM_OWS_20HZ_Wrapper(); 

private: 

void  register_interest_in_events();  Declares  the  registration  for  wrapper  execution  events 

}; 

OWS_Wrapper:  :OWS_Wrapper() : 

theA5ADP_ptr_(A5ADP_Device:  :instance{)),  Establishes  the  ADP  data  instance 

theA5AFCS_ptr_{A5AFCS_Device::lnstance()), 

theASAI  U_ptr_{A5AI  U_Device: :  Insta  nce{)) , 

theA5EDU_ptr_{A5EDU_Device::lnstance()), 

theA5UPACS_ptr_{A5UPACS_Device::lnstance()), 

theA5WeightOffWheelsjDtr_{A5WeightOffWheels_Device::lnstance()), 

theA5INS_ptr_(A5INS_Device::lnstance{)) 

{ 

}; 

REAL  OWS_Wrapper::GetMOST_RECENT_DiSPLAY_NZ()  Sample  variable  processing 

{ 

REAL  temp37; 

temp37  =  PIM.MOST_RECENT_DISPLAY_NZ; 
return  temp37; 

}; 

void  OWS_Wrapper::PERFORM_OWS_20HZ_Wrapper()  20  Hz  wrapper  processing 

{ 

ADC_C_PiM.mach_number  =  (theA5ADP_ptr_->GetMach())->GetVaiue();  Gets  current  Mach  No.  from  Host 

ADC_C_PIM.Iocal_angle_of_attack  =  {theA5ADP_ptr_->GetLocalAngleOfAttack())->GetAngle(); 
ADC_C_PIM.Iocal_angle_of_attack_valid  =  (theA5ADP_ptr_->GetLocalAngleOfAttack())->lsValid{); 
ADC_C_PIM.baro_corrected_pressure_altitude  =  {theA5ADP_ptr_->GetBaroCorrectedPressureAltitude{))->GetValue{); 
ADC_C_PIM.true_angle_of_attack  =  {theA5ADP_ptr_->GetTrueAngleOfAttack())->GetAngle(); 

ADC_C_PIM.pressure_ratio  =  {theA5ADP_ptr_->GetPressureRatio())->GetValue{); 

AFCS_C_PIM.Ianding_gear_handle_is_up  =  theA5AFCS_ptr_->GetLandingGearFlandlelsUp(); 

AFCS_C_PIM.Iateral_stick_force  =  (theA5AFCS_ptr_->GetLateralStickForce{))->GetValue(); 
AFCS_C_PIM.Iateral_stick_force_is_valid  =  theA5AFCS_ptr_->GetLateralStickForcelsValid(); 
AFCS_C_PIM.Ieft_stab_main_ram_pos_is_valid  =  theA5AFCS_ptr_->GetLeftStabMainRamPoslsValid(); 
AFCS_C_PIM.I_h_stabilator_ram_position  =  {theA5AFCS_ptr_->GetLFI_StabRamPosition{))->GetValue(); 
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AFCS_C_PIM.r_h_stabilator_ram_position  =  {theA5AFCS_ptr_->GetRH_StabRamPosition())->GetValue{); 
AFCS_C_PIM.right_stab_main_ram_pos_is_valid  =  theA5AFCS_ptr_->GetRightStabMainRamPoslsValid{); 
AFCS_C_PlM.roll_rate  =  (theA5AFCS_ptr_->GetRollRate())->GetValue(); 

AFCS_C_PIM.roll_rate_is_valid  =  theASAFCS  _ptr_->GetRollRatelsValid{); 

AFCS_C_PIM.spin_recovery_display  =  theA5AFCS_ptr_->GetSpinRecoveryDisplay(); 

AFCS_C_PIM.yaw_rate  =  (theA5AFCS_ptr_->GetYawRate{))->GetValue{); 

AFCS_C_PIM.yaw_rate_is_valid  =  theA5AFCS_ptr_->GetYawRatelsValid(); 

AFCS_C_PIM.yaw_rate_tone_priority  =  theA5AFCS_ptr_->GetYawRateTonePriority{); 
MPDP_C_PIM.cau_normal_acceleration  =  (theA5AFCS_ptr_->GetNormalAcceleration())->GetValue{); 
INS_C_PIM.normal_acceleration  =  (theA5INS_ptr_->GetNormalAcceleration())->GetValue{); 

OWS_20HZ_PIM_TRANSFER_OWS_20HZ_Transfer_To_Ada();  Transfers  C  PIM  data  to  Ada  PIMs 

}} _ 
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Appendix  D.  Sample  WrapidH  Ada  Listing 


--  File  generated  by  WrapidH,  version  1 .1 


WITH  D_ADC_C_PIM; 

WITH  D_ADC_20HZJNPUT_PIM; 

WITH  D_AFCS_C_PIM; 

WITH  D_AFCS_20HZJNPUT_PIM; 

WITH  D_MPDP_C_PIM; 

WITH  D_INS_C_PIM; 

WITH  DJNS_20HZJNPUT_PIM; 

WITH  D_MPDP_20HZJNPUT_PIM; 

WITH  D_HUD_CONTROL_PIM; 

WITH  D_GEN_20HZ_UNPACK_PIM; 

WITH  D_GEN_10HZ_UNPACK_PIM; 

WITH  D_OWS_20_HZ; 

WITH  D_OWS_20_HZ_PIM; 

WITH  D_OWS_20_HZ_C_PIM; 

WITH  OWS_Stubs; 

WITH  U_NUMBER_TYPES; 

WITH  INTERFACES.C; 

WITH  U_BASIC_DATA_TYPES; 

WITH  U_MPDP_TYPES; 

PACKAGE  OWS_20HZ_PIM_TRANSFER  IS 


Uses  Wrapper  ADC  PIM  loaded  by  processing  above  (Mach  No.,  etc.) 
Uses  Legacy  OWS  ADC  data  input  PIM 


Uses  Legacy  OWS  output  PIM 

Uses  Wrapper  output  PIM  that  receives  data  for  transfer 


Uses  C/ Ada  interfaces 


PROCEDURE  OWS_20HZ_Transfer_To_Ada; 

PRAGMA  EXPORT(C,  OWS_20HZ_Transfer_To_Ada,  "OWS_20HZ_PIM_TRANSFER_OWS_20HZ_Transfer_To_Ada") ; 

END  OWS_20HZ_PIM_TRANSFER; 

PACKAGE  BODY  OWS_20HZ_PIM_TRANSFER  IS 

PROCEDURE  OWS_20_HZ_Copy_Outputs  IS 

BEGIN 

D_OWS_20_HZ_C_PIM.OWS_20_HZ_C_PIM.MAX_NEGATIVE_MAGNITUDE_G  := 
INTERFACES.C.C_float{D_OWS_20_HZ_PIM.PIM.MAX_NEGATIVE_MAGNITUDE_G); 

D_OWS_20_HZ_C_P  I M .  OWS_20_HZ_C_P  IM .  MAX_POSITI VE_M AGN  ITU  DE_G  > 
INTERFACES.C.CJIoat(D_OWS_20_HZ_PIM.PIM.MAX_POSITIVE_MAGNITUDE_G); 

D_OWS_20_HZ_C_PIM.OWS_20_HZ_C_PIM.MOST_RECENT_DISPLAY_NZ  := 
INTERFACES.C.C_float(D_OWS_20_HZ_PIM.PIM.MOST_RECENT_DISPLAY_NZ);  Interface  OWS  output  to  Wrapper 
D_OWS_20_HZ_C_PIM.OWS_20_HZ_C_PIM.NZ_RECALL_TABLE  := 
INTERFACES.C.CJIoat(D_OWS_20_HZ_PIM.PIM.NZ_RECALL_TABLE); 

D_OWS_20_HZ_C_PIM.OWS_20_HZ_C_PIM.WARNlNG_RATIO_RECALL_TABLE  > 
INTERFACES.C.C_float{D_OWS_20_HZ_PIM.PIM.WARNING_RATIO_RECALL_TABLE); 

END  OWS_20_HZ_Copy_Outputs; 

PROCEDURE  OWS_20HZ_Transfer_To_Ada  IS 
temp65  :  U_MPDP_TYPES.GP_ROTATING_BIT_PATTERN_TYPE; 

BEGIN 

D_ADC_20HZJNPUT_PlM.PIM.TRUE_ANGLE_OF_ATTACK  > 
U_BASIC_DATA_TYPES.ELEVATION_TYPE{D_ADC_C_PIM.ADC_C_PIM.true_angle_of_attack); 

D_ADC_20HZJNPUT_PIM.PIM.MACH_NUMBER  := 


U_NUMBER_TYPES.REAL(D_ADC_C_PIM.ADC_C_PIM.mach_number);  Copy  Wrapper  Mach  No.  into  OWS  input  PIM 

D_ADC_20HZJNPUT_PIM.PIM.PRESSURE_RATIO  := 
U_NUMBER_TYPES.REAL{D_ADC_C_PIM.ADC_C_PlM.pressure_ratio); 

D_ADC_20HZ_INPUT_PIM.PIM.BARO_CORRECTED_PRESSURE_ALTITUDE  := 
U_NUMBER_TYPES.REAL{D_ADC_C_PIM.ADC_C_PIM.baro_corrected_pressure_altitude); 

D_ADC_20HZJNPUT_PIM.PIM.LOCAL_ANGLE_OF_ATTACK  > 
U_NUMBER_TYPES.REAL(D_ADC_C_PIM.ADC_C_PIM.IocaLangle_of_attack); 

D_ADC_20HZ_INPUT_PIM.PIM.LOCAL_ANGLE_OF_ATTACK_VALID  > 
Boolean{D_ADC_C_PIM.ADC_C_PIM.Iocal_angle_of_attack_valid); 

D_AFCS_20HZJNPUT_PIM.PIM.R_H_STABILATOR_RAM_POSITION  > 
U_NUMBER_TYPES.REAL(D_AFCS_C_PIM.AFCS_C_PIM.r_h_stabilator_ram_position); 

D_AFCS_20HZJNPUT_PIM.PIM.L_H_STABILATOR_RAM_POSITION  > 
U_NUMBER_TYPES.REAL(D_AFCS_C_PIM.AFCS_C_PlM.Lh_stabilator_ram_position); 

D_AFCS_20HZJNPUT_PIM.PIM.ROLL_RATE  >  U_NUMBER_TYPES.REAL{D_AFCS_C_PIM.AFCS_C_PIM.rolLrate); 

D_AFCS_20HZ_INPUT_PIM.PIM.MODE_DlSCRETE_WORD.LANDING_GEAR_HANDLE_IS_UP 

Boolean{D_AFCS_C_PIM.AFCS_C_PIM.Ianding_gear_handle_is_up); 

D_AFCS_20HZJNPUT_PlM.PIM.MODE_DISCRETE_WORD.YAW_RATE_TONE_PRIORITY  > 
Boolean{D_AFCS_C_PIM.AFCS_C_PIM.yaw_rate_tone_priority); 

D_AFCS_20HZJNPUT_PIM.PIM.MODE_DISCRETE_WORD.SPIN_RECOVERY_DISPLAY> 

Boolean{D_AFCS_C_PlM.AFCS_C_PIM.spin_recovery_display); 

D_AFCS_20HZ_INPUT_PIM.PIM.VALlDITY_WORD.YAW_RATE_IS_VALID  > 
Boolean(D_AFCS_C_PIM.AFCS_C_PIM.yaw_rate_is_valid); 

D_AFCS_20HZ_INPUT_PIM.PIM.VALIDITY_WORD.ROLL_RATEJS_VALID  := 
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Boolean{D_AFCS_C_PIM.AFCS_C_PlM.rolLrateJs_valid); 

D_MPDP_20HZ_INPUT_PIM.PIM.CAU_NORMAL_ACCELERATION  > 
U_NUMBER_TYPES.REAL(D_MPDP_C_PIM.MPDP_C_PIM.cau_normaLacceleration); 

DJNS_20HZJNPUT_P1M.PIM.NORMAL_ACCELERATION  := 
U_NUMBER_TYPES.REAL{D_INS_C_PIM.INS_C_PIM.normaLacceleration); 

D_HUD_CONTROL_PIM.PIM.AOA_LIMIT.DISPLAYED_VALUE  >  U_NUMBER_TYPES.INTEGER_SH0RT(1 .0); 
D_GEN_20HZ_UNPACK_PIM.PIM.SPIKE_CHECK_DATA_IS_SPIKED(TRUE_AOA)  >  Boolean(FALSE); 
D_GEN_20HZ_UNPACK_PIM.PIM.SPIKE_CHECK_DATA_IS_SPIKED(LOCAL_AOA)  >  Boolean{FALSE); 
D_GEN_20HZ_UNPACK_PIM.PlM.SPIKE_CHECK_DATA_IS_SPIKED(MACH_NUMBER)  >  Boolean{FALSE); 
D_GEN_20HZ_UNPACK_PIM.PIM.SPIKE_CHECK_DATA_IS_SPIKED{PRESSURE_RATIO)  >  Boolean(FALSE); 
D_GEN_20HZ_UNPACK_PIM.PIM.SPIKE_CHECK_DATAJS_SPIKED(BARO_CORR_PRESS_ALTITUDE)  > 
Boolean(FALSE); 

D_GEN_20HZ_UNPACK_PIM.PIM.SPIKE_CHECK_DATA_IS_SPlKED{PRESSURE_ALTITUDE)  >  Boolean{FALSE); 
D_GEN_20HZ_UNPACK_PIM.PIM.SPIKE_CHECK_DATA_IS_SPIKED(NORMAL_ACCELERATION)  >  Boolean(FALSE); 
D_GEN_10HZ_UNPACK_PIM.PIM.CFT_STATUS_FLAG  D_GEN_10HZ_UNPACK_PIM.CFT_TYPE(CFT_4); 
temp65 

OWS_Stubs.Next_GP_ROTATING_BIT_PATTERN(D_MPDP_20HZ_INPUT_PlM.PIM.GP_ROTATING_BlT_PATTERN); 

D_OWS_20_HZ.PERFORM_OWS_20HZ;  Execute  the  Legacy  OWS  20  Hz  processing 

OWS_20HZ_Transfer_To_Ada.OWS_20_HZ_Copy_Outputs;  Copy  the  Legacy  outputs  to  the  wrapper 

END  OWS_20HZ_Transfer_To_Ada; 

END  OWS  20HZ  PIM  TRANSFER; _ 
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